On Aug 19, 2010, at 19:25, David Weintraub wrote: > On Wed, Aug 18, 2010 at 6:56 PM, Greg Alexander 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.
Well, no, he's not proposing modifying the content of the files, only adding a property. > 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. Only commits immediately after adding a new file will be a commit by the hook script, to add the property. For commits that just modify existing files, there will be no need for the hook script to commit anything. > 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. Yes, I too would recommend he use this strategy instead. Reject bad commits entirely; soon developers will learn how to make good commits on the first try. > 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. Right. The user should explain to us in more detail, with examples, why he believes locking is necessary.