On Wed, Aug 18, 2010 at 6:56 PM, Greg Alexander <greg_at_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
qazwart_at_gmail.com
Received on 2010-08-20 02:26:24 CEST