Ben Collins-Sussman wrote:
> 2. Support 'depth 0' directory locking only. That is, the ability to
> lock a directory's props and membership. This means not being able
> to add or delete immediate children, but still being able to edit
> children.
I feel that this could be a useful compromise, but I will not be sure
until we have thrashed out the implications of the semantic overlap
between a dir lock (which, we are saying, locks collection membership
among other things) and a lock on a file within that dir (which, we have
said, locks its membership of its parent dir among other things).
> The counterargument, though, is that users are going to want to lock
> whole trees no matter what.
Yes, and it would be logically inconsistent to have file locks but not
dir locks; but there is clearly a much more imminent need for file
locking. Tree rearrangements are relatively infrequent, and conflicts
are relatively easy to resolve (or so my intuition says). As long as we
allow for dir locks in future, I think it's fine to just do file locks
for now. During the implementation and trials of file locks, we would
probably learn things that will help not only in the implementation but
also in the design of dir locks.
> But: who says recursive locks need to be done via inheritance?
>
> cmpilato has an interesting set of ideas:
>
> * Add support for file locking.
[...]
> * Add support for depth-0 locks on directories.
[...]
> * 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.
There might be some holes in that implementation. The sort of thing I
mean is: if a file or dir is added, it does not inherit the lock; if it
is then (partially) committed, then within that tree in the repository
there is an unlocked part, which is probably not what the user wanted.
The client side could try to maintain the illusion of a single recursive
lock, by propagating it to things that are added, etc. - but that is
complicated. Indeed, locks on some of the sub-trees or files might be
broken by other users, and then there would be no way to maintain the
illusion of it being a single recursive lock. It would have to be
presented as a hierarchy of individual locks, just like properties set
by a recursive "propset" are.
I'm not saying it's not feasible - just that there might be some rough
edges to this emulation of recursive locks.
> * 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.
Again, is that semantically a good enough emulation of depth-infinity
locks to comply with the DAV spec?
- Julian
---------------------------------------------------------------------
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:05:16 2004