On Fri, Aug 20, 2010 at 12:42 PM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > 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.
"Properties" of file are part of the file content in the necessary Subversion database. They require a revision to commit. Doing that as a post-commit is.... potentially quite awkward and destructive if a bug creeps into the script and it recurses, spewing hundreds or thousands of revisions into unattended operation that you, as a remote Subversion user, have no graceful way to stop. It's a very dangerous idea. >> 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. And you'll be able to detect this, reliably, how? Remember that the data available to a post-commit script has to be parsed, and with multilingual file names or non-7-bit ASCII filenames it can get tricky. >> 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. Amen. I wouldn't necessarily call them "good" commits, but you need compliant commits for this. >> 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. As opposed to having tag, or a release tag area, be locked.
