Justin Erenkrantz wrote:
> --On Monday, April 11, 2005 4:21 PM -0500 kfogel@collab.net wrote:
>> Anyway, +1 on "svn:wants-lock".
>
> I'm against changing the name away from 'svn:needs-lock' as we can find
> issues no matter what the name is. I think we've entered bikeshed land
> myself. =)
Probably.
> I'd recommend that we have ship a pre-commit hook example (or include it
> in the documentation?) to have a commented out check to verify that
> svn:needs-lock property isn't present or that the commit has the lock.
>
> I do think making the lock mandatory will end up being a very common use
> case here: people will want to enforce that a needs-lock commit actually
> do have the lock.
Why? We've discussed this before and I disagree. The way I see it, there is
absolutely no point in demanding that a lock be present before committing,
because all it does is force people who find themselves wanting to commit a
file that isn't locked to type:
svn lock file
svn commit file
(which will either succeed if no-one else has it locked, or will fail at the
first stage if someone else has)
whereas, if the policy is "you _want_ to use a lock", the use just types:
svn commit file
(which fails or succeeds in just the same way except that in this case it's the
"commit" command that might fail).
Surely the point of your perceived desire to force users to take a lock is that
you want to force them to take a lock before editing the file? Please tell me
what is the point of enforcing that a lock be held at commit time. There may
be valid reasons such as wanting to ensure that the repository locking hooks
are triggered for every file that is committed, but I don't hear that argument
being made and I'm not sure it would stand scrutiny anyway.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 02:47:46 2005