Julian Foad <julianfoad@btopenworld.com> writes:
> > 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.
Are we sure this discussion belongs here, or even deserves to exist? :-)
Julian wasn't proposing that Subversion enforce this behavior, only
that Subversion offer the ability to enforce it, to be decided by each
repository's policy. If the debate is simply whether or not to ship
with this particular commented-out template in a hook script,
well... then we truly are painting the bikeshed, and I withdraw.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 03:01:41 2005