The functional spec says:
> If a directory is locked, the owner of the lock has the exclusive
> right to change the directory's list of entries and properties, to
> delete the directory, and to move the directory. This lock applies
> recursively to all files and directories under the locked directory.
I believe that if we want our locking implementation to be within the
realm of acceptable simplicity, we need to punt on directory locks,
which address a completely different need from the sane handling of
non-mergeable files. For those who believe otherwise, please answer
the following questions:
* Does the svn:lock property on a directory imply that every file
underneath the directory must be locked before modification, and
should therefore be read-only in the working copy when not locked?
- If not, then I can locally modify a file and someone else can
later lock a directory above it, leading to a conflict on a
locked file, something which isn't supposed to happen without
hijacking of some form. So I will assume yes.
* When the client checks out a directory, how does it discover
whether one of the parent directories has the svn:lock property,
so that it can know whether to make all the files read-only?
* When the client checks in a locked file, the lock is normally
released, but the "lock" may actually be a parent directory lock,
in which case it is presumably not released unless the checkin
covered the entire parent directory. How does the client
determine whether the file should be reverted to read-only state?
I can probably come up with more questions later. Is this feature
really worth a whole new class of ghudson bugs?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 07:41:20 2004