> I'm not sure why I'm replying to this, as it seems like
> flamebait... however Joshua has been very polite in his findings. :-)
I'm not sure whether to take offense to that or not... ;)
The point is, a programmer's productivity is of utmost concern to me in
my job. Subversion is a very important product to me, but I can't
recommend a product (when it hits 1.0) if it is going to waste a lot of
time.
I've just published some new statistics (including CVS) from my machine.
All I can say is I must've set up the Apache server wrong or something,
because the numbers for the activities I've tested thus far are not very
good for Subversion. :(
> This seems true... Berkeley DB is probably the culprit here.
> I wouldn't be surprised to learn that BDB is slower than
> whatever proprietary DB perforce is using.
Perforce uses Berkeley DB with a proprietary schema for its database
files and some form of RCS for everything else.
> > * Retrieving new files from Perforce is significantly faster than
> > Subversion.
>
> The svn client must 'walk' the entire working copy in order
> to report its state to the server. Perforce doesn't need to do this.
I can't imagine this is it. There isn't a working copy yet. All files
being transferred are new. No directories have been created.
> > * Branching files is significantly faster than Subversion. This
> > operation will happen far less frequently, though, but
> still takes a
> > long, long time.
>
> Try creating a branch server-side:
>
> svn cp URL1 URL2
I will try this later.
> 'svn merge' is receiving diffs from the server, and applying
> them to the working copy. The slowness you're seeing is in
> the commit, as you say.
>
> Just as with updates, it takes 30 seconds for svn to commit,
> because it must 'walk' over the entire working copy,
> searching for changed files. Perforce doesn't need to do this.
Could be, except other commits only took a few seconds, as I previously
reported, on the same directory structure. Something must be different.
> Again, this is just a matter of Berkeley DB. Not a surprise
> that a BDB database is bigger than a perforce DB. Someday
> svn will be using any number of SQL back-ends... they'll
> probably be even bigger.
> :-)
I'm not a system admin or anything, but I do know this. It is a pain in
the neck to continually upgrade hard drives at my place of work. It is
downtime for everyone. It happens unexpectedly, because there is no
dedicated admin monitoring the disk space every three seconds. It is
frustrating.
Assuming everyone is going to have large amounts of disk space is like
assuming all servers will have 2+ gigs of RAM. It isn't going to
happen. Do you really want Subversion to be confined to a niche market
or do you want everyone to use it? I'm far more likely to use a piece
of software that makes efficient use of the resources it is given. Just
my opinion...
> Honestly, Joshua, these are the benchmarks we care most
> about. At this time, Subversion's goal is to replace CVS...
> *not* to be explicitly better than Perforce, Bitkeeper,
> Clearcase, etc.
Subversion's features largely make it on par with Perforce. That's why
I provide (and will continue to provide) the Perforce comparison.
> If you repeat your tests comparing CVS and SVN, we'd be very
> interested. It would be even better if you can run your
> tests with a network separating the client from the repository.
The timings are posted. I was unable to have the repository on a
separate network. I don't believe those timings are as valid, though,
as network bandwidth can dramatically affect the outcome. If it isn't
efficient locally, it definitely won't be efficient remotely.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:36:20 2002