organization

[Craig Boston]

On Tue, Mar 29, 2005 at 11:34:11PM +0200, Joerg Sonnenberger wrote:
> That's not true. There are two major problems with subversion, compared
> to CVS:
> - the size of the working copy is doubled (because of the local cache)
> - annotation is linear in the number of revisions (of a file?)

Not trying to spread false information about Subversion -- I like it
very much and use it for all my personal projects :)  Just stating my
opinion based on observations made while using it.

> The first can be work-arounded by using SVK, but often is also an
> advantage, because e.g. diff is a pure local operation which doesn't
> have to contact the server.

Well, you don't have the extra working copy files, but you usually end
up eating up at least as much space for your local repository mirror;
unless you have a lot of working copies checked out.

> On the other hand, CVS definitely doesn't scale to large repositories too,
> just think about the time a "cvs up" or "cvs tag" needs. You can't make
> everything fast, it is a compromise between speed, disk space and not to
> forget atomarity.

Keeping in mind that the tests I ran were back in the pre-1.0 days
(right before 1.0 IIRC), Subversion was much faster on update, but
significantly slower for checkout and diffs.  Those operations scaled
worse than O(n) as the repository grew.

It would be interesting to run some more benchmarks (clkao's mirror
eliminates much of the import hassle) and see how the latest subversion
compares.  Also, as Bruce reminded me, the new fsfs storage backend may
have different characteristics that need to be taken into account.

Of course Subversion fares much better on the atomicity issue, that's a
given :)

svk may be able to help too.  I tried it for a while but eventually gave
up because getting the perl bindings installed and working was a bit of
a black art.  Probably time to try the port again.

Craig