1 |
dberkholz wrote: |
2 |
> > 4. |
3 |
> > Doing more test migrations, and having a test-plan for comparing them |
4 |
> > directly, as well as against other SCMs. |
5 |
|
6 |
> The OpenSolaris link above is quite useful for comparisons, and the |
7 |
> "Repository Formats Matter" post from Keith Packard is helpful for |
8 |
> understanding one good reason why git might be the best choice. |
9 |
|
10 |
reading "Repository Formats Matter" again, finally made me try git a |
11 |
little more thoroughly. but honestly - all i care about, is that we |
12 |
switch away from CVS. no other VCS is that bad... |
13 |
|
14 |
> Same as above, what are our requirements and what doesn't matter? Here's |
15 |
> the OpenSolaris list: |
16 |
> http://opensolaris.org/os/community/tools/scm/dscmreqdoc/ |
17 |
|
18 |
> Important |
19 |
> - Fast branching (This will make it possible for new styles of |
20 |
> development in Gentoo.) |
21 |
> - Fast committing (This will encourage more atomic commits from a |
22 |
> functional POV.) |
23 |
> - Reliable (Repository format & committing process guarantee no |
24 |
> corruption.) |
25 |
> - Usability (This can be either discoverable or through good |
26 |
> documention, found elsewhere or produced by us.) |
27 |
> - Modifiable (Written in a reasonably common language. Read: Python, C |
28 |
> or shell. git and bzr qualify, darcs doesn't.) |
29 |
> - Active upstream (Getting modifications into upstream code, |
30 |
> requesting features) |
31 |
> - Hooks (Implement custom checks upon commit to your or main |
32 |
> repository.) |
33 |
> |
34 |
> Optional |
35 |
> - Partial checkouts. They aren't useful enough to be a requirement, in |
36 |
> my view, because I have yet to hear a good reason they're needed. A |
37 |
> gig or two of disk space is cheap. |
38 |
> - Integration into popular text editors |
39 |
> - CVS gateway (people can still commit using CVS) |
40 |
> - Shallow checkouts (Only getting partial history to reduce size. git |
41 |
> supports grafting two repositories together, not sure about other |
42 |
> SCMs. Not sure how to do the initial splice. Explore |
43 |
> 'git-filter-branch'?) |
44 |
|
45 |
AFAICT git fits the bill for all important and most optional points. |
46 |
|
47 |
> Another point I'd like to get into is how we should architect this. |
48 |
> Should we stick with the single repository for the whole thing, or |
49 |
> should we break it down so that each package has its own repository? If |
50 |
> we go with the latter, we need to figure out a way to easily check out & |
51 |
> update the whole repo. |
52 |
|
53 |
thinking about repository changes may drag the conversion to another VCS |
54 |
out indefintively. for that reason we should limit our selves to |
55 |
currently just picking a new VCS and then later discuss the changes we |
56 |
may want to do to the repository layout (the ebuild dir comes to mind)... |
57 |
|
58 |
..but lets get the ball rolling. drobbins is already publishing a git tree |
59 |
and we should make sure we dont get overtaken from left AND right... :) |
60 |
|
61 |
best regards |
62 |
Thilo |