Hello everyone !
I believe there might be some problems with very large working copies.
I checked out my whole vendor-drop repository location to a WC, because
I want to do reorganizations, and I wanted them to be a single atomic
My vendor drop is organized like this:
/ <-- repos root
vendor/ <-- WC root
I want to rename all current/ to trunk/ and move all version tags to a
tags folder. Additionaly, I want to reorganize so that some vendor
drops are under a common root. For example, all Apache projects go
together, Jakarta projects go together, etc.
Server and client are on the same physical machines, and the machine is
a P4 3.0 Ghz, 1 Gb RAM and 80 Gb 7200 RPM HD. OS is Windows XP SP2, and
SVN is 1.1.1 [svn, version 1.1.0 (r11180)].
Checkout was fine. Took lots of time, but that was to be expected,
given the size of the checkout.
The problem occured when I started moving. I executed the following
from the root of my WC:
$ svn mkdir jakarta
$ svn move log4j jakarta
Believe it or not, the SVN client grew to use almost 300 Mb of RAM. I
have a picture of the Windows Task Manager with the memory and CPU graph
The whole move operation took something like 20 or 30 minutes (didn't
keep track - I expected things to go much faster). It looks like the
move operation operated in three distinct phases:
1. WC locking phase seemed to use an unbounded amount of memory - 300 MB
for my WC. This took almost half of the runtime;
2. After the peak had been reached, memory usage stayed constant, or
near enough. This part took about half of the runtime too;
3. WC unlocking began, and finished pretty quickly. Seemed like 30
seconds to a minute. Memory usage quickly dropped back to zero at that
I don't have exact statistics, but my WC has 53 libraries, each with a
current/ and, on average, two version tags (so 3 * 53 = 159 vendor
drops), and each vendor drop contains hundreds of files and folders.
What I suspect is going on here is that SVN is locking the whole WC,
instead of locking the parent (vendor/) folder, and the two children it
is interested in (log4j/ and jakarta/).
Is that to be expected ? Am I missing some locking behavior here ?
Should I forget about one single atomic commit, and do everything
server-side instead ? I know it'll be much faster. Using the bindings
[a reason to learn how to do it, I guess ;)], is it possible to do
multiple server-side moves ?
Received on Thu Nov 25 16:36:55 2004
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org