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 |
> |