My company is starting to use subversion, and we expect the respository to
reach several gigabytes in size. When someone finds a bug, I want them to
make a tag of exactly what the user had in their source directory when
they found the bug, so that others can reproduce the results and fix the
bug. It's not enough to tag the files that they started with, as a "cvs
tag" would do; I need to check in all of their modified files to the tag
directory as well. This seems like the perfect time to take advantage of
the "svn copy WC URL" command.
However, I'm noticing that copies from WC to URL do not scale well when
working on a large repository, and I'm concerned that this type of copy
will be too slow to use. I ran some tests using Subversion 1.1.3 on an
AMD Opteron 2GHz. It's a BDB repository on a local 80GB SATA disk with an
ext3 filesystem. I have checked in 1.7gig in 23357 files, spread across
For each command, I ran it several times since disk caching affects the
1) svn status takes 19.1s, 2.9s, 2.8s, 2.9s
2) svn update takes 32s, 15.7s, 15.9s, 16.6s.
3) svn copy $REPOS/trunk $REPOS/tags/tag1 takes 1.2s, 1.1s. (Wow!)
4) svn copy working-copy $REPOS/tags/tag2 takes 172s, 181s. (Hmm.)
My question is why is #4 so slow, and what can I do about it? Based on
watching vmstat, it seems to go through three phases. The first 20% of
the time, it's doing I/O, the middle 60% of time it's doing intensive CPU
operations (user time), and during the final 20% of the time it's doing
lots of I/O again.
I'm surprised because I'd expect the copy operation to work something like
- svn update/status to see which files have been changed. estimated time:
- use the cheap "svn copy URL URL" method to copy the files that have not
been changed. estimated time: 1s.
- use the slower "svn copy WC URL" method to copy the files that have been
changed. estimated time 0s because there are no files that have been
changed in this case.
I'm sure it's more complicated than this, but I'm having trouble
explaining where all the time goes. And at this rate, if my repository
grows by 4x this copy/tag operation will be unacceptably slow. Any
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jan 27 23:21:18 2005