On Wed, May 28, 2014 at 6:13 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
> Only via a pre-commit hook script on the server which checks the
> incoming transaction & disallows the commit if there are any
> lock-required files which aren't locked by the committing user.
>
> However, I would suggest that if your process is such that you're
> requiring a lock be held by the committing user even if no other user
> has a lock at that time, you need to re-examine your tools or
> processes as this is irregular and outside what one would consider
> "normal" for locking scenarios.
I actually think such a hook makes sense; I considered making one a few times.
The problem with allowing the commit of "needs-lock" files, when the
committer does not actually have a lock, is that it gets people in the
habit of manually overriding the readonly setting to make changes. It
also gets people in the habit of just starting to make changes without
checking for other people having a lock first. By requiring users to
get a lock before committing a file which you've already indicated
NEEDS a lock to make changes, it encourages good behavior rather than
workarounds. People in general are lazy and will always fall into the
easiest workflow they can get away with.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3079391
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-05-28 15:33:04 CEST