On 16.11.2013 00:57, Rick Varney wrote: > Branko Čibej <brane <at> wandisco.com> writes: > >> >> You're allowed to modify and commit changes to a file that has the >> svn:needs-lock property regardless of whether it's locked or not. >> svn:needs-lock is not a constraint, it's just a reminder. > I see. I was thinking of it as a constraint, because we had customized our > setup to prevent checking in unlocked files in our pre-commit hook script.
Sure, you can use a pre-commit hook to prevent committing files without locks; but there's nothing you can do to prevent anyone from editing it, short of using advanced access control in the working copy directories and modifying or otherwise wrapping the Subversion command-line client. > Maybe this behavior can be made optional, enabled via the > configuration file? Changing client behaviour via config file options is almost always a bad idea ... every such option makes testing more complex and bug triage more time consuming. I'm not saying that there's no chance we'd ever change the way 'svn delete' behaves; I only stated some of the arguments against that, and there can certainly be other opinions. But we'd have to see some indication that the case you describe is actually moderately common. Frankly, I doubt it is; because mandatory locking isn't, in my experience, a very common workflow with Subversion. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
