Greg Hudson wrote:
> 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?
Yes (if we support svn:lock on a directory, which C-M Pilato doesn't
care about, but I think it would be illogical not to).
> * 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?
The server tells it, perhaps as a one-shot "a recursive lock applies to
all this" or perhaps as an individual note on each file. It doesn't
sound to me like a very hard problem. The server can find out easily
enough.
> * 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?
The client tells the server which locks it wants to release. Assuming
everything is in order, the server allows this and the client either (1)
therefore thinks it knows (according to the information it got at the
last update) whether any locks still apply to the files and so whether
to make them read-only again (the effect is stale lock information just
as can happen in other ways); or (2) requests an update of all the lock
information for these targets from the server, and then knows for sure
whether any locks still apply.
> I can probably come up with more questions later. Is this feature
> really worth a whole new class of ghudson bugs?
You have a point. It probably is too complicated for a first cut at the
feature.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 18:42:14 2004