I'm trying to use Subversion with a client's legacy codebase. Performance is
unacceptable, and it all has to do with client-side locking. This is, I
think, related to Issue 1452.
This codebase has over 25,000 directories.
Even a real good dev box with a fast hard drive takes 10-15 minutes to
perform a lock operation - before it tries to actually do anything. Of
course, it then takes a similar amount of time to unlock everything when it
is done - even if the action is cancelled.
Although the operation itself may scale only with the amount of change, the
locking scales with the size of the total repository. Each time that we
branch the code, the problem gets worse (that is, if we ever check out the
branch).
Some operations can be done in subdirectories. Those then go quickly.
However, this codebase is poorly organized, so most changes are endemic.
Thus, all updates always have to be from the top of the tree. They take 30
minutes to tell you that the current working set is up to date.
It seems to me, as one unfamiliar with the gory details, that a simple,
constant-time locking operation is possible. It would just lock, at the
beginning of the operation, the top of the tree which it is operating on. It
would not note any lock in any subdir. When checking for locks, again only
at the beginning of an operation, the system would simply walk up the tree,
checking for a lock at each encountered directory.
The problem that I see is if I operate on a subdir, then do an operation on
a parent of it, before the subdir operation completes. This, however, could
be fixed by a slight modification: define two types of locks. The first
indicates that the tree from there down is locked. The second is a warning -
it indicates that there is a locked subtree in the current tree. The locking
algorithm, then, would be something like:
1. Search from the current directory to the root. For each directory, see if
there is a lock. If so, the system is already locked with another operation
(exit algorithm).
2. If you don't encounter a lock, then set a warning in every directory
traversed (from current up to root). Set a lock in current.
3. Perform operation.
4. Remove the lock. Remove all warnings. *
* In order for this to work, you'd need to be able to allow multiple-warning
for a directory. That way, if you are doing two operations in subdirs of a
directory A, they could both independently increment the "warning level" for
dir A. When they finish, they both decrement the warning level. Thus, the
warning remains active until all have completed.
I am, of course, not going to write this myself. However, I'd really
appreciate it if some solution to the long locking problem were added to
Subversion. As it is, using Subversion on our LAN is only marginally faster
than using Perforce across the internet.
Thanks in advance for any improvements you can make to the lock scaling
problem.
Arlo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 14 17:56:22 2005