1 |
On Wed, 28 Mar 2007 07:58:59 -0400 |
2 |
Chris Gianelloni <wolf31o2@g.o> wrote: |
3 |
|
4 |
> Please, everyone, go back and read the actual *facts* that were |
5 |
> discovered using copies of *our* repositories before going around |
6 |
> using data from outside sources. |
7 |
|
8 |
Alec Warner's test results are here, of course: |
9 |
|
10 |
http://www.gentoo.org/proj/en/infrastructure/cvs-migration.xml |
11 |
|
12 |
FI on gentoo-x86 we're doing about 10,000 commits a month (from 100 to |
13 |
500 commits a day), according to my #gentoo-commits logs. (Assuming |
14 |
the SVN revision is a 32-bit number, it'll take about 1000 years to |
15 |
saturate). |
16 |
|
17 |
Personally I'm a fan of SVN over CVS, but that's from a client |
18 |
perspective not the server. It would be interesting to find out why |
19 |
SVN consumes double the bandwidth to checkout a full tree. It would |
20 |
also be interesting to find out why the server disk usage is 4x that of |
21 |
CVS (and what difference the choice of back-end makes). |
22 |
|
23 |
FWIW the things I like in SVN, in order of importance to me are: |
24 |
1) ability to do diffs off-line |
25 |
2) maintains history when copying, moving etc (e.g. 'svn log' of CPV-r2 |
26 |
traces the history back through the point at which it was copied |
27 |
from CPV-r1) |
28 |
3) command line is largely the same as CVS (which avoids confusion |
29 |
when moving between CVS and SVN repositories) |
30 |
|
31 |
Alec - any chance you could flesh out exactly what tests you did? I |
32 |
would have expected that the update-diff-commit cycle that we (well, |
33 |
repoman) typically do would be more efficient on SVN than CVS, in |
34 |
terms of the amount of data transferred between the client and server |
35 |
(svn client sends diffs, cvs client sends whole files, and the diff |
36 |
operation in the repoman cycle would be local in svn). |
37 |
|
38 |
-- |
39 |
Kevin F. Quinn |
40 |
|
41 |
-- |
42 |
Kevin F. Quinn |