[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: John Szakmeister <john_at_szakmeister.net>
Date: 2004-10-21 04:18:15 CEST

On Wednesday 20 October 2004 16:28, Ben Collins-Sussman wrote:
> Hm, lots of discusison on directory locking. Fitz and cmpilato and I
> had a chat this morning, and want to relay some ideas.
>
> What sort of options do we have?
>
> 1. Punt. Don't have any directory locking.
[snip]
> cmpilato has an interesting set of ideas:
>
> * 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?

While I'd really like to see the ability to lock a portion of the tree,
I'm definitely in the "punt" camp. I think we should definitely look at
this in 2 phases. First, get exclusive file locks in place and out the
door. Secondly, take a look at the broader issues that directory locking
represents, and how to solve it more elegantly. I see a need for
inherited properties, and I think recursive directory locks will lead to
solutions for this and other beasts such as ACLs. :-)

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 21 04:18:35 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.