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?
- 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 15:55:03 2004