>>>>> "Christopher" == Christopher Ness <chris@nesser.org> writes:
Christopher> 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.
Christopher> That blanket statement is not true. What does diff run
Christopher> as with local modifications in both CVS and SVN?
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
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.
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.
Christopher> Perhaps you should use a normal sized repository. For
Christopher> example lets look at subversion itself which is a
Christopher> non-trivial product:
That's nice, but Subversion is just a single application.
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.
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.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 15 15:06:11 2005