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.
Received on 2010-08-20 18:43:43 CEST