[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Locking functional spec comments

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2004-10-13 15:17:54 CEST

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.