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
> > 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)...
..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... :)
signature.asc (This is a digitally signed message part.)