[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: More performance

From: Christopher Ness <chris_at_nesser.org>
Date: 2005-09-15 05:15:36 CEST

On Wed, 2005-09-14 at 09:19 -0400, Paul Koning wrote:
> Ben> I expect it will take almost as long to run 'svn update', 'svn
> Ben> status', or 'svn commit'. These are all situations where you're
> Ben> telling the client to do a walk over a gigantic working copy.
> That's depressing. If true, it would mean that Subversion across the
> board is 3x slower than CVS.

That blanket statement is not true. What does diff run as with local
modifications in both CVS and SVN?

Have you looked at the network usage of SVN vs. CVS? Checkouts should
obviously be about the same, but other commands like update I would
expect you to see a difference.

How many developers do you know of that work on a project with > 70,000
files and > 1.5Gb of code? I don't know of too many.

Perhaps you should use a normal sized repository. For example lets look
at subversion itself which is a non-trivial product:

[nesscg@heidrun grep-subversion]$ svn info
Path: .
URL: http://svn.collab.net/repos/svn/trunk
<snip />
[nesscg@heidrun grep-subversion]$ svnversion
[nesscg@heidrun grep-subversion]$ du -sh
69M .

Since this is a working copy, that means SIZE = REPORTED_SIZE/2 and get
~35M of source code. And there is a website in there too, as well as
documentation and tools to support SVN.

Perhaps your projects are as big as the tests you are running, but you
*should* always use the smallest possible subset as a working copy.


PGP Public Key: http://www.nesser.org/pgp-key/
23:02:38 up 2 days, 6:02, 2 users, load average: 0.21, 0.22, 0.34

Received on Thu Sep 15 05:17:17 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.