--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
locks....)
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