> > updating on a p4 is quite a hit on a p4 with fast ide disk for more
> > than 2.5 minutes, with 25000 files/dirs versioned, including
> > tags/branches.
>
> So your working copy was fully at HEAD, and it took 2.5 minutes to
> traverse 25000 files/dirs?
>
> All that svn had to do was read every entries file exactly once, and
> noticed if you had any mixed revisions. Once it determined you
> didn't, it sent a single REPORT http request that said "I have
> everything at revision 302", and the server response should be nearly
> empty, saying "no need to change anything.
>
> So the network shouldn't have been the issue here. To verify this,
> can you run an ethereal trace and see if the final REPORT
> request/response is as small as I expect?
>
> Assuming that's true, why does it take so long to read all those entry
> files? For example, when I run 'svn up' on my svn tree, it takes 1.4
> seconds:
The number of "little" files in the .svn directories does matter if the
working copy is on a network filesystem.
Subversion has great performance until you start using a working copy
over something like NFS and then its orders of magnitude slower than
CVS.
Client-server interaction may be optimized, but I think everyone forgot
to consider that the "cheap" disk access may not be that cheap under
real working conditions.
Of course, we are past the point where this can be easily fixed but I
thought I'd mention it (again).
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jan 10 19:14:43 2003