Share common / useful SVN pre-commit hooks

Question

What are some common and/or useful pre-commit hooks for SVN?

Solution 1

We have a post commit hook that posts the message to a twitter account. Uses twitsvn (disclaimer: I'm a committer on that project).

Silly? Maybe...but it turned out to be a good way for us to communicate the goings-on of our repository to some of our version-control-challenged team members. Once SVN started talking to them via their twitter client, it didn't feel so much like a black box.

Solution 2

That a user has actually entered a comment on the commit message, and that it contains a particular issue number to track.

Solution 3

Checking for absolute paths in various text files (i.e. VRML, XML etc). Most of the checked-in code should never have absolute paths, yet some people and tools insist on producing hard-coded stuff.

Solution 4

• Check for tabs and reject the check-in.
• Check for inconsistent line endings and reject the check-in.
• Check for occurance of "CR: [username]" and reject the check-in if there is no code review.

Solution 5

I do a word count on submit messages. They need to be 5 words or more. This has led to some comedic insults against me...

View more solutions

Comments

[Instantsoup]

Why would this get a down vote?

[Jonathan Holloway]

Yeah great, non constructive feedback !

[emmanuel honore]

Never thought about to solve this problem by pre-commit...

[ICTMitchell]

After sufficiently many botched revisions I just implemented this mainly for myself (I've moved to DVCS:es now, which allows one to continue commiting until the offending strand works well enough for merge.) However, the guys were consistently glad when the hook stopped their mistakes from becoming public, so adding these things is a good idea.

[ICTMitchell]

It might be that forcing issue numbers aren't the favourite. I can see the good thing, but if I spot a small bug it's easier to just fix it rightaway than logging into the bug system and record a new issue for it. It depends on your process and tools, but I can understand those who don't like that enforcement.

[ICTMitchell]

That's not pre-commit but post-commit.

[Instantsoup]

It sure is easier to fix right away. Unfortunately there's no audit. We enforce issue numbers so our QA department can verify bug fixes make it into both the production branch and trunk to avoid regressions.

[the_mandrill]

We use this pre-commit hook to require that devs enter comments. It's handy for (a) enforcing use of comments (some newcomers to SCM took a while to realise the benefits of this), and (b) preventing you from accidentally committing without leaving a message.

[San Jacinto]

I don't like the "particular issue to track" part because of the pains that it causes. If there is a real bug, then I like the idea of attaching it to a bug. However, if I am creating a new feature, now I have to create a bug in order to commit code. Messy. Additionally, there is no good way in the tools right now to link bugs together based upon what context of the code has been modified, so often times we are left to endless searching to find the changes we want. Our SW lead sees this hook as a good idea, i do not.

[Jonathan Holloway]

Maybe you can hash it out with him or beat each other with plastic swords or something... Bug fixes can be linked via a bug fix release version... new features can be linked and grouped together via user stories...

[San Jacinto]

@Jon unfortunately, he's not the most open-minded person. It isn't the end of the world for me; I just do it and move on with my day. Sometime he'll understand why our particular implementation isn't the best.

[Vinko Vrsalovic]

My tracker tracks bug as well as features...

[Admin]

actually this should be done in svn:ignore not in a pre-commit hook.

[gbjbaanb]

I'm not so sure - we're talking 'universal' ignore patterns, so unless you want ignore properties in every directory (and thus difficult to modify if you need to add a new pattern) you need something a little more 'centralised'. I think svn is missing true global properties (eg held on the server, not each client)

[ICTMitchell]

What if the build takes 5-10 minutes? I'm intrigued, but it seems difficult.

[Jason]

likely better off doing some kind of lint checking instead, then using cruisecontrol.sourceforge.net or something to handle the builds

[Craig Curtis]

Thats what a ci server is for...

[Dieter Gribnitz]

I've just done that as well # config section $numberOfWords = 3; $svnlook = '/usr/bin/svnlook'; #-------------------------------------------- $repos = $ARGV[0]; $txn = $ARGV[1]; $comment = $svnlook log -t "$txn" "$repos"; chomp($comment); if ( $comment !~ m/((\b[\S]{2,}\b)\s*){$numberOfWords,}/ ) { print STDERR "Please enter more detail in your commit message.\n"; exit(1); } exit(0);

[iuiz]

I don't understand why this answer got a down vote. There are many toolchains that use automatic tests, that are executed after commiting, or at least once a day. When this fails everyone gets an email and development is stopped until it is fixed. However if the build takes 5-10 minutes there might be a better way to do this, but I don't think thats a reason to downvote this answer, as it may give other users some nice ideas.

[demoncodemonkey]

Check for tabs? What do you mean?

[bta]

@demoncodemonkey - One common thing specified in coding standards is whether programmers should indent using tabs or using spaces. On projects that strictly enforce coding standards, the pre-commit hook can detect (for instance) lines that use tabs for indentation and either reject the commit or automatically convert them to spaces.

[demoncodemonkey]

Aha... OK, I understand. Thanks :)

[jamil ahmed]

Yeah, it should be check for "tabs or spaces, whatever your coding style specifies." Personally, I prefer spaces, but that's a different holy war. :)

[Nicolaj Schweitz]

the links to the scripts are broken in the first link. The second one is good. svn.apache.org/repos/asf/subversion/branches/scons-build-sys‌​tem/…

[ICTMitchell]

Check that there are no mixed tabs/spaces in indentation could be a good thing though. Softer than a full LINT, but still useful.

[Malcolm]

check-mime-type.pl is now: svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scrip‌​ts/…

[Roger]

Email is so two thousand and late...

[jpo38]

"Check for tabs and reject the check-in" could you share this one?

[jamil ahmed]

Heh, that was years ago. I don't have it handy anymore.