[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: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-10-20 23:21:55 CEST

--On Wednesday, October 20, 2004 3:28 PM -0500 Ben Collins-Sussman
<sussman@collab.net> wrote:

> * Add support for file locking.
> These are represented as lock-tokens in the WC. The UI for
> this has been discussed to death already.
> * 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.
> * 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.
> * When talking to a DAV client, honor both depth-0 and
> depth-infinity directory locking requests.
> Again, we emulate a depth-infinity lock by performing a depth-0
> lock on everything beneath.
> What do others think of this approach?

Sounds fine. While I like the depth-infinity strategy you outlie here, my
initial thought is that the acquisition needs to be done atomically: such
that if a child has an outstanding lock, no locks are taken out. But,
then, once you have the lock, someone *could* break the individual lock: so
what point is atomicity in gaining the locks then? So, something still
strikes me as odd and having individual locks could make this approach
useless in practice. (Breaking a child lock would not break the parent

But, again, I think our consensus short-term strategy is to go after #1
(file locking) and (perhaps) #2 (depth-0 collection locking). Then, after
we're happy there, we can re-evaluate the wisdom (or not!) of
depth-infinity locks once we have some real implementation behind us. So,
yes, I think we should punt on depth-infinity and come back to this later.
-- justin

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 23:22:22 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.