Julian Foad wrote:
> Garrett Rooney wrote:
>
>> Julian Foad wrote:
>>
>>> 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.
>
>
> But in the unenforced scenario, the administrator would just put that
> same restriction in the pre-commit hook instead, wouldn't he?
True, I guess he would be able to do that.
I suppose the svn:lock property doesn't make a whole lot of sense unless
it's enforcing 'lock this before you can edit it' by setting the file to
read-only or something, like perforce does.
-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 16:03:10 2004