I'm in the process of changing us over from CVS to SVN at work, mainly to
take advantage of SVN's cheap branching. We're planning on modifying our
workflow to use a one-branch-per-bug model, which will simplify our lives
considerably during the code review and merging processes. Of course,
we'll make heavy use of the 'svn switch' operation.
I'm a bit disappointed in the performance of 'svn switch' on a working
copy over an NFS mount. We're running on (unfortunately) somewhat old SUN
hardware. Our repository consists of approximately 2300 files and
directories, and a switch from one branch to a nearly similar branch takes
over 4 minutes.
stracing the svn client reveals the following points of note:
0.0000s - some sort of wc check
0.1682s - tree lock, read entries files
3.5427s - open .svn/tmp/tempfile.tmp
3.5448s - scan wc directories, getdents64
5.7612s - contact repository over socket, do stuff
5.9175s - read wcprops for each file & dir & then set to 'END'
141.????s - do actual wc updates
143.1844s - read wcprops for each file & dir & then set to new value
267.9598s - write new entries files
275.6327s - close & rm .svn/tmp/tempfile.tmp, unlock tree
277.2784s - operation complete
The wcprop operations account for ~259s of the 277s. Therefore, the
direction I'm headed is to try an eliminate as many of the wcprop
operations as I can. I don't know a lot yet about the guts of Subversion,
but my current thoughts:
1) Can wcprops be eliminated entirely? Why aren't they just stuffed into
the entries file? My guess is that the file is seperate for a good
reason, but if so, what is it?
2) Can switch just skip the step that sets all wcprops to END? The second
'set wcprop' step just overwrites the old version anyway. That change
would shave off 135s, about 50% of the time.
3) Can some of the wcprops operations be eliminated? There's lots of
redundant calls during each iteration (format is read over and over again,
lots of lstat64s on the same file, etc.)
I'm planning on spending more time on this, but in the meantime, any
feedback or pointers would be appreciated.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Apr 9 03:39:20 2004