Re: Subversion transactions within post-commit

On Tue, Aug 2, 2011 at 4:03 PM, Ray Rashif <schiv_at_archaudio.org> wrote:
> We have a _local_ checkout of the repository on our server, and our
> post-commit hook needs to run svn-add, svn-rm and svn-ci commands in
> that checkout. All of these commands run fine. For eg. (within the
> post-commit script):

NO! NO! NO! AUUUGGGHHH!

Never update a repository with a hook.! That's why you're given the
relatively safe "svnlook" command. It allows you to look, but not
touch a repository.

Think of it this way, the user must wait until the post-commit hook
finishes. So, that means the user must wait until you've updated your
working directory, manipulated what you need, and then commit those
changes back.

Besides, there's the issue of recursion. Your hook script does a
commit which runs another hook script which runs another commit.

And, then there's the issue of a user making a set of changes, and
finding out that their working directory is out of date with changes
they didn't make.

Finally, there's the Finger 'o Blame which is dying to point to the
scapegoat who messed things up. You want the Finger 'o Blame to point
to the user who committed the transaction. Otherwise, you end up with
this:

Boss: Dammit, we have to delay the release and miss the release date.
Why was the code messed up?

Developer: It wasn't my fault. It worked on my machine. It was that
stupid post-commit hook that CM put on! It broke my code.

See, Finger o' Blame points right at you.

You didn't say what you're doing and why, so I can't say how you want
to do it. However, these usually fall into the category of "fixing"
the committed files. For example, you want to reformat the code to be
in the correct format. Instead, either put this as part of a
pre-commit trigger and simply fail the commit, or use a continuous
build system like Hudson or Jenkins to test the situation.

For example, users are suppose to run checkstyle on their code before
committing. You want to run checkstyle and fix the code. Instead, have
Jenkins or Hudson run Checkstyle, then mark the revision as bad and
email the user if checkstyle finds issues. Jenkins/Hudson will email
the user.

> Now comes the interesting part. As soon as I add a commit transaction,
> say, AFTER those commands, ALL of them FAIL at the SAME TIME:
>
> echo "Updating.."
> svn up
> echo "Adding..."
> svn add $whatever
> echo "Committing..."
> svn ci -m "$whatever"
>
> gives us:
>
> Updating...
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
> Adding...
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
> Committing...
> svn: Working copy '.' locked
> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Well, the repository is locked because another user is in the middle
of a commit transaction, and you're attempting to do another commit.
Although it is a post-commit hook, and the repository is already
modified, the commit is still going on.

See:

<http://svnbook.red-bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks>

for more information.

-- 
David Weintraub
qazwart_at_gmail.com