On Fri, Aug 20, 2010 at 12:42 PM, Ryan Schmidt
<subversion-2010b_at_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.
Received on 2010-08-21 13:04:58 CEST