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:
>> http://opensolaris.org/os/community/tools/scm/dscmreqdoc/
>
>> 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
>