Julian Foad wrote:
>>> B. Summary
>>>
>>> We recommend implementing a lightweight locking mechanism.
>>> @@ -26,7 +30,7 @@
>>> and enforce locking policies. Provide a series of client
>>> commands for creating, removing, breaking, and stealing locks.
>>> Lastly, create a new property to communicate that a path must be
>>> - locked before committing.
>>> + locked before committing. ### Pointless.
>>
>>
>> How is it pointless? See section II.B.2.
>
>
> OK - it is not pointless to have a communication system. We just need
> to be clear about what its purpose is, as it _is_ pointless to enforce
> that a path must be locked (just) before committing. Here's why (as
> summarised in my introductory paragraph at the beginning of the e-mail).
>
> If a user wasn't going to lock the file before committing, and then we
> force them to lock it before committing, no benefit results from doing
> so. They try to lock it before committing; if that succeeds, then they
> can commit it but also they would (in the unenforced scenario) have been
> able to commit it anyway. If they fail to get a lock, then they would
> not have been able to commit it in the unenforced scenario. So what's
> gained?
>
> The only thing I can see that would be useful is if we could try to
> ensure that a lock is taken out before the user starts to modify the
> file. If that's what this sentence is aiming at, then it should say so.
It's not totally pointless. Requiring a lock to be taken out also
requires the pre-lock hook script to fire, which means that the
administrator has the ability to say "you can't lock this file". That
might be useful in some situations.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 15:18:08 2004