On Wed, Aug 18, 2010 at 6:56 PM, Greg Alexander <g...@alexanderzone.com> wrote: > I am a very new Subversion user and am trying to get a post commit hook script > working. My Subversion is running on linux. The script I want to add would > add the > needs-lock property to every file that didn't have a lock. Any pointers on > this would > be great. I have searched and not found any good, working, examples on how to > do this.
A couple of things: First of all, your attempt to modify code in a hook script: Not cool. In Subversion, a hook script runs on the server and doesn't have access to the developer's working directory. You COULD do a checkout, modify the files, then recommit, but that would mean your hook script is modifying code which could cause an error. The whole idea is to have the developers responsible for their code and making sure their code is tested and everything is right. Yet, your hook script modifies the code and never tests it. Also imagine the logs: Bob did a fix, hook script did a fix. Robert did a fix, hook script did a fix. Alice did a fix, hook script did a fix. Every other log entry is your hook script modifying code. If you want to make sure that the code is correctly formatted, or there's a certain property on the file, you use a pre-commit hook to fail the commit if the developer doesn't have things done correctly. After a couple of times, the developers learns to make these checks before a commit. Now, about the svn:needs-lock property. For 20 or so years, developers had to lock their files before editing. This was part of the design of the first version control system, SCCS and later RCS. You were suppose to get all of the files, then mark the ones you want to edit, modify them, and commit them. It was thought this was the only way you could run a version control system. And, it was a pain. People would lock files and forget to unlock them. Development would be delayed while locks had to be broken. CVS changed all of this. In CVS, you made your changes and committed them. If someone committed before you did, you simply updated that file and tried again. Developers loved it. Development was faster and easier, and all modern version control systems followed suit. You simply edit and commit. You can do what you want, but why? It means you, as the administrator will be spending much of your time breaking locks. You'll see developers get into fights about file editing. And for what? CVS has been around now for 20 years and has shown that lockless version control not only works, but is vastly superior to the kind that made you lock files before editing. -- David Weintraub qazw...@gmail.com
