Gentoo Archives: gentoo-scm

From: Alec Warner <antarus@g.o>
To: Thilo Bangert <bangert@g.o>
Cc: gentoo-scm@l.g.o
Subject: Re: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS
Date: Sun, 05 Oct 2008 22:31:04
Message-Id: b41005390810051531l504bd373pd82b072ef379a1bf@mail.gmail.com
In Reply to: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS by Thilo Bangert
1 On Sun, Oct 5, 2008 at 2:59 PM, Thilo Bangert <bangert@g.o> wrote:
2 > dberkholz wrote:
3 >> > 4.
4 >> > Doing more test migrations, and having a test-plan for comparing them
5 >> > directly, as well as against other SCMs.
6 >
7 >> The OpenSolaris link above is quite useful for comparisons, and the
8 >> "Repository Formats Matter" post from Keith Packard is helpful for
9 >> understanding one good reason why git might be the best choice.
10 >
11 > reading "Repository Formats Matter" again, finally made me try git a
12 > little more thoroughly. but honestly - all i care about, is that we
13 > switch away from CVS. no other VCS is that bad...
14 >
15 >> Same as above, what are our requirements and what doesn't matter? Here's
16 >> the OpenSolaris list:
17 >> http://opensolaris.org/os/community/tools/scm/dscmreqdoc/
18 >
19 >> Important
20 >> - Fast branching (This will make it possible for new styles of
21 >> development in Gentoo.)
22 >> - Fast committing (This will encourage more atomic commits from a
23 >> functional POV.)
24 >> - Reliable (Repository format & committing process guarantee no
25 >> corruption.)
26 >> - Usability (This can be either discoverable or through good
27 >> documention, found elsewhere or produced by us.)
28 >> - Modifiable (Written in a reasonably common language. Read: Python, C
29 >> or shell. git and bzr qualify, darcs doesn't.)
30 >> - Active upstream (Getting modifications into upstream code,
31 >> requesting features)
32 >> - Hooks (Implement custom checks upon commit to your or main
33 >> repository.)
34 >>
35 >> Optional
36 >> - Partial checkouts. They aren't useful enough to be a requirement, in
37 >> my view, because I have yet to hear a good reason they're needed. A
38 >> gig or two of disk space is cheap.
39 >> - Integration into popular text editors
40 >> - CVS gateway (people can still commit using CVS)
41 >> - Shallow checkouts (Only getting partial history to reduce size. git
42 >> supports grafting two repositories together, not sure about other
43 >> SCMs. Not sure how to do the initial splice. Explore
44 >> 'git-filter-branch'?)
45 >
46 > AFAICT git fits the bill for all important and most optional points.
47 >
48 >> Another point I'd like to get into is how we should architect this.
49 >> Should we stick with the single repository for the whole thing, or
50 >> should we break it down so that each package has its own repository? If
51 >> we go with the latter, we need to figure out a way to easily check out &
52 >> update the whole repo.
53 >
54 > thinking about repository changes may drag the conversion to another VCS
55 > out indefintively. for that reason we should limit our selves to
56 > currently just picking a new VCS and then later discuss the changes we
57 > may want to do to the repository layout (the ebuild dir comes to mind)...
58
59 Except some VCS are more usable with different repo layouts; how do
60 you intend to reconcile these differences?
61
62 >
63 > ..but lets get the ball rolling. drobbins is already publishing a git tree
64 > and we should make sure we dont get overtaken from left AND right... :)
65 >
66 > best regards
67 > Thilo
68 >

Replies