Julian Foad wrote:
> The obvious motivation for not being allowed to move a file that is
> locked by someone else is that if you could, and wanted to change it
> while it was locked by someone else, you could just move it out of the
> way, copy it back and change the copy. That would be very annoying to
> the person who had "locked" it, and they would feel like the lock had
> been violated. I'd agree.
>
> But...
>
> If I'm working on the text of doc/book/book/ch01.xml, and have it
> locked, and other people have various other chapters locked, and then a
> project manager wants to rename "doc" to "documents", shouldn't he be
> able to do so without disturbing us? I don't know, but maybe. There
> will probably be other use cases in which we would want it to be locked
> in its absolute location.
That's how it works for WebDAV. The lock is on "doc/book/book/ch01.xml",
but it 'protects' the complete URL; thus you can't MOVE any of the
ancestor collections unless you have the lock token.
> So...
>
> We need to decide whether "can't move a locked file" means "can't move
> it from or within its parent directory" or "can't change its absolute
> location, i.e. can't move it or any of its parents". I now suggest the
> former (contrary to what my suggested patch to
> locking-functional-spec.txt said).
>
> And...
>
> While we don't yet feel ready to implement or even define recursive
> directory locks, we might at least want to consider it as a possible
> idea, and we might well want to implement non-recursive directory locks.
> In either case, the restriction of a directory lock is going to be (at
> least) "you can't move files that are direct children of this
> directory". That meaning overlaps with the meaning of a lock on a file.
> Is that semantic overlap going to cause difficulties?
In WebDAV terminology: content, properties *and* collection membership
constitute the lockable state of a resource; that is, having a shallow
lock on a collection means you can't change it's direct membership
without having the lock.
Best regards, Julian Reschke
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 14 19:31:43 2004