"Stephen C. Tweedie" <sct@redhat.com> writes:
> I was quite surprised that the copy took that long:
>
> $ time svn copy file:///home/rcs/SVN/kernel/{base,linux-2.4.19-pre9}
>
> Committed revision 6.
>
> real 1m9.354s
> user 0m19.060s
> sys 0m1.290s
Yikes, I just reproduced this. It's *definitely* a bug. The whole
design of our repository was to make tagging a constant-time
operation. It should only take a couple seconds at most... it's just
adding a single copied node.
It turns out that this is a bug (cmpilato thinks) from a recent change
to the way we deltify previous revisions after a commit.
However, I don't think we'll fix this bug; we're about to have the
entire guts of libsvn_fs rewritten this week. It's not worth it.
>
> Even doing a simple "svn up" null operation where the entire wc is
> already at the latest version is taking a long time --- about 18
> seconds if the entire tree is already in cache, 1 minute 5 seconds
> from cold, and strace is showing a lot of write activity inside the wc
> for what should be a noop.
It is a noop from the server's point of view, but not the client's.
'svn up' has to stat every single file in your working copy no matter
what -- it has to send a complete description of the working copy to
the server. If your working copy is truly up-to-date, then the server
sends no data back. (CVS works the same way... except that our
state-reporting is actually much faster.)
Nevertheless, oftentimes you may have just committed the latest
repository revision... meaning that a few files in your wc are at
HEAD, and all the rest are a HEAD-1. When you 'svn up', the server
still sends back no data, but every item in your wc must have its
working revision "bumped" up to HEAD. This means reading and
re-writing every .svn/entries file in the whole tree. That's the
write activity you're seeing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 1 14:23:19 2002