On Thu, 2005-09-15 at 09:04 -0400, Paul Koning wrote:
> >>>>> "Christopher" == Christopher Ness <chris@nesser.org> writes:
<snip />
> Christopher> Have you looked at the network usage of SVN vs. CVS?
> Christopher> Checkouts should obviously be about the same, but other
> Christopher> commands like update I would expect you to see a
> Christopher> difference.
>
> I was expecting that too, from the book. But then Ben commented that
> "svn switch" was slow because it had that big tree to traverse, and I
> should expect other commands to suffer likewise. Frankly, that
switch was an extreme example. Most commands do walk the entire tree in
the working copy which takes time but do not modify the accounting
information for each file. If your client machines are under powered
but on a fast network CVS might still be a better solution for you.
If you have people distributed around the world on slow networks though,
they will not be happy with your choice. SVN trades off bandwidth for
hard drive space and client CPU cycles.
> doesn't make much sense, because if it were an unavoidable consequence
> of the repository size, CVS should be just as slow, and it isn't.
SVN takes cycles on the clients machine to describe the minimal set of
changes to the server instead of having the server blast entire files
back to the client.
This takes time before even talking to the server. CVS - as I
understand it - just brute forces it's changes back to the client.
> Christopher> How many developers do you know of that work on a
> Christopher> project with > 70,000 files and > 1.5Gb of code? I
> Christopher> don't know of too many.
<snip />
> The repository is what it is because it contains all the pieces that
> go into our product -- which is a rather large embedded system. A
> piece of it is NetBSD, so that brings in the whole source tree for
> that, which is big already. (Consider that a large application like
> gcc is just one subtree underneath NetBSD.) And then there is a whole
> lot of other imported stuff, and all the code we wrote.
You were able to break your product down into components in the above
paragraph. Likely some developers work across component lines, but I'd
think the NetBSD guys work in that code base, the other imported stuff
and "all the code you wrote".
Working copies are cheap, you can have as many as you'd like. That is
instead of one holistic working copy of trunk or a branch.
Of course builds would be an exception that need a full working copy or
export.
> We're currently using CVS. My task is to find a replacement for CVS
> that works better. If Subversion does work better with our
> repository, then it's a leading candidate. If Subversion isn't
> capable of dealing effectively with repositories that size, then it is
> not a candidate. Or at the best it would be a candidate only if there
> isn't anything else, i.e., we have no choice but to spend the
> engineering effort to redesign our repository, and development
> procedures, and build scripts, etc...
>
> Yes, if we were to start over we probably should have constructed
> things differently. But we didn't, and changing is not cheap or
> simple.
Fair enough.
I simply am observing that you are abusing the tool and giving it a poor
performance report by not following best practices.
Perhaps you should talk to the KDE developers and see what they have to
say about subversion and orders of scaling.
Cheers,
Chris
--
PGP Public Key: http://www.nesser.org/pgp-key/
09:29:30 up 1:23, 2 users, load average: 0.10, 0.39, 0.81
Received on Thu Sep 15 16:01:18 2005