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
In Reply to: [gentoo-scm] Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS by Thilo Bangert
On Sun, Oct 5, 2008 at 2:59 PM, Thilo Bangert <bangert@g.o> wrote:
> dberkholz wrote: >> > 4. >> > Doing more test migrations, and having a test-plan for comparing them >> > directly, as well as against other SCMs. > >> The OpenSolaris link above is quite useful for comparisons, and the >> "Repository Formats Matter" post from Keith Packard is helpful for >> understanding one good reason why git might be the best choice. > > reading "Repository Formats Matter" again, finally made me try git a > little more thoroughly. but honestly - all i care about, is that we > switch away from CVS. no other VCS is that bad... > >> Same as above, what are our requirements and what doesn't matter? Here's >> the OpenSolaris list: >> > >> Important >> - Fast branching (This will make it possible for new styles of >> development in Gentoo.) >> - Fast committing (This will encourage more atomic commits from a >> functional POV.) >> - Reliable (Repository format & committing process guarantee no >> corruption.) >> - Usability (This can be either discoverable or through good >> documention, found elsewhere or produced by us.) >> - Modifiable (Written in a reasonably common language. Read: Python, C >> or shell. git and bzr qualify, darcs doesn't.) >> - Active upstream (Getting modifications into upstream code, >> requesting features) >> - Hooks (Implement custom checks upon commit to your or main >> repository.) >> >> Optional >> - Partial checkouts. They aren't useful enough to be a requirement, in >> my view, because I have yet to hear a good reason they're needed. A >> gig or two of disk space is cheap. >> - Integration into popular text editors >> - CVS gateway (people can still commit using CVS) >> - Shallow checkouts (Only getting partial history to reduce size. git >> supports grafting two repositories together, not sure about other >> SCMs. Not sure how to do the initial splice. Explore >> 'git-filter-branch'?) > > AFAICT git fits the bill for all important and most optional points. > >> Another point I'd like to get into is how we should architect this. >> Should we stick with the single repository for the whole thing, or >> should we break it down so that each package has its own repository? If >> we go with the latter, we need to figure out a way to easily check out & >> update the whole repo. > > thinking about repository changes may drag the conversion to another VCS > out indefintively. for that reason we should limit our selves to > currently just picking a new VCS and then later discuss the changes we > may want to do to the repository layout (the ebuild dir comes to mind)...
Except some VCS are more usable with different repo layouts; how do you intend to reconcile these differences?
> > ..but lets get the ball rolling. drobbins is already publishing a git tree > and we should make sure we dont get overtaken from left AND right... :) > > best regards > Thilo >