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.
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?
- Julian
---------------------------------------------------------------------
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:17:09 2004