List Archive: gentoo-scm
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
"Thilo Bangert" <firstname.lastname@example.org>
"Alec Warner" <email@example.com>
Re: Re: Welcome to Gentoo-SCM discussion, for figuring out Gentoo beyond CVS
Sun, 5 Oct 2008 15:31:01 -0700
On Sun, Oct 5, 2008 at 2:59 PM, Thilo Bangert <firstname.lastname@example.org> 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:
>> - 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
>> - 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
>> - 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
> 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