[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: another idea for directory locking.

From: Mark Benedetto King <mbk_at_lowlatency.com>
Date: 2004-10-21 00:31:24 CEST

On Wed, Oct 20, 2004 at 03:28:38PM -0500, Ben Collins-Sussman wrote:
> * Add support for depth-0 locks on directories.
> Also represented as a lock-token in the WC. We're still in the
> process of discussing the UI for this, but all-in-all, it seems
> workable. It's only a tiny bit more complex than a file-lock.

I'll treat that as axiomatic.

> * Make 'svn lock -R dir' automatically take out a depth-0 lock on
> every subdir it can find, and a normal file-lock on every file it
> can find.
> We get a reasonable emulation of 'recursive locking' this way,
> without having to deal with nasty inheritance. A working copy
> just ends up with a whole bunch of lock-tokens, rather than a
> single one.

This could be quite a few locks. Let's ignore that, for now.

Let's say we have a repository:


Joe has a WC that points at /foo.
Jane has a WC that points at /foo.

Joe does "svn lock -R ." at the same time that Jane
does "svn lock -R bar".

Joe gets a lock on /foo.
Joe gets a lock on /foo/a.
Joe gets a lock on /foo/b.
Jane gets a lock on /foo/bar.
Jane gets a lock on /foo/bar/c.
Joe tries to get a lock on /foo/bar, fails.

In this case Jane wins. Joe probably needs to roll back all of
his locks.

I believe that there are cases where both would need to abort
unless we can acquire all locks in a well-ordered way. That
may be solvable by making sure that within a directory we lock
by lexicographic repository-path order. That would be a lot
like traditional S2PL deadlock avoidance, and would probably
work (in that it would guarantee that only one locker would
be forced to abort).


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 00:28:33 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.