--- kfogel@collab.net wrote:
> Bruce Cropley <cropleyb@yahoo.com.au> writes:
> > We're also seeing speed problems locally. A
> checkout
> > from CVS was around 12m here. With SVN it is 36m+.
> > Updates and commits also feel slower, though we
> > haven't timed them as much yet.
> >
> > Is there an FAQ for SubVersion speed issues?
> > I've found lots of tips and possibilities in the
> > mailing lists over the last week, but many of them
> are
> > for problems that have been fixed.
> >
> > We'd really like to be able to use SubVersion,
> mainly
> > so we can rearrange our mainline with confidence.
> But
> > the speed from overseas is currently so much of an
> > issue that we may have to revert to CVS. Are these
> > times expected? Does anyone have any suggestions
> as to
> > what we can try?
>
> "svn checkout is slow" is not the same as
> "subversion is slow".
Sorry if I over-generalised. I have been using SVN for
nearly a year here on another, much smaller project,
and it has been great.
The operations that are noticeably slower for us are:
checkout, update, commit and log.
> Some operations will be slower than CVS, others
> (say, diff) will be
> faster. Checkouts are slower than CVS's, usually.
> Obviously, we'd
> prefer for checkouts to be faster, but it hasn't
> been our highest
> priority either, since it's not a common operation
> for most people.
Automatic builds typically check out the entire source
from scratch. At least, they did in the world of CVS.
> I'm kind of surprised that commits are slower;
> updates I'm not sure.
> We'd have to see comparisons of same client/server
> hardware, same
> operations, I guess.
Another operation that is causing speed problems for
us is reviewing commit logs. Here's what a developer
in LA reported to me (referring to lack of $Log$
support):
"I understand I can go to the source control system to
look up changes and that feature of seeing all changes
in one check-in is terrific. The fact that to get the
list of changes for one file takes the same time as to
get the list of changes for all files – about 3
minutes for me each time is annoying (when CVS took
5-10 seconds and SOS took 1-2 seconds); but since I’m
getting extra information maybe it is OK. I’ll
reserve judgement."
FWIW, I did some timings of svn log (using
svnserve)versus cvs log locally, and timing with
cygwin.
I'm not seeing the same times for all files versus one
file - I think that might be an exageration.
A single large source file with 25 revisions:
CVS SVN
Initial 0.39s 0.60s
Subsequent 0.35s 0.27s
For a frequently modified directory (489 SVN
revisions):
CVS SVN
Initial 1.2s ~6s (could be dodgy)
Subsequent 0.6s 2.7s
And for a bigger directory (1400 SVN revisions):
CVS SVN
Initial 23s 12.6s
Subsequent 3.6s 7.1s
I hope that it interesting and useful. :)
Is SVN log speed likely to improve in 1.2 or 1.3?
Thanks again,
Bruce
Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 4 05:57:21 2005