What are some common and/or useful pre-commit hooks for SVN?
-
15one that fails for a specific user on even numbered days of the month? – crashmstr May 19 '09 at 19:32
-
"The question you are asking appears to be subjective and is likely to be closed." – Michael Myers May 19 '09 at 19:33
-
Should this be a community wiki? it is subjective, and doesn't ask to solve a particular problem. – Dan Davies Brackett May 19 '09 at 19:35
-
I think it could be edited to actually be useful, but in its current incarnation should be closed. – Instantsoup May 19 '09 at 19:36
-
2Indeed it is subjective, but it can teach us on hooks people use, which is more useful (though less funny) than "what is your favorite comics strip" One request to the all people answering - can you please post the code of the hook? (if possible) – David Rabinowitz May 19 '09 at 19:38
-
A question on useful things to do in SVN pre-commit hooks would be both useful and interesting, but that's not what this is. Unless it gets edited. – Michael Myers May 19 '09 at 19:52
22 Answers
That a user has actually entered a comment on the commit message, and that it contains a particular issue number to track.

- 62,090
- 32
- 125
- 150
-
2
-
13
-
1
-
3It 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. – Macke May 19 '09 at 20:33
-
7It 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. – Instantsoup May 19 '09 at 21:09
-
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. – the_mandrill Nov 19 '09 at 22:43
-
1I 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. – San Jacinto Nov 22 '09 at 22:11
-
1Maybe 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... – Jonathan Holloway Nov 22 '09 at 22:36
-
@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. – San Jacinto Nov 23 '09 at 01:35
-
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.

- 24,812
- 7
- 82
- 118
-
-
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. – Macke May 19 '09 at 20:31
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...

- 68,394
- 30
- 171
- 212
-
1I'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); – sleep-er Mar 12 '10 at 14:49
- 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.

- 53,608
- 15
- 131
- 222
-
-
1@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. – bta May 23 '11 at 20:46
-
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. :) – i_am_jorf Sep 01 '11 at 02:47
-
1
-
You might want to take a look at: http://svn.apache.org/repos/asf/subversion/branches/1.6.x/www/tools_contrib.html#hook_scripts (This page might be outdated obviously it is not maintained anymore for Subversion 1.7)
Or directly at: https://svn.apache.org/repos/asf/subversion/trunk/contrib/

- 605
- 8
- 10
-
the links to the scripts are broken in the first link. The second one is good. https://svn.apache.org/repos/asf/subversion/branches/scons-build-system/www/tools_contrib.html#hook_scripts – Nicolaj Schweitz Jan 19 '12 at 12:28
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.

- 4,547
- 3
- 24
- 25
I like using svn
hooks to:
- enforce the stricter points of code style
- check for obvious syntax errors
- make sure special Trac keywords like "Fixes" or "Addresses" are actually preceding the appropriate issue number

- 303,634
- 46
- 339
- 357
I check the filetype and make sure that certain banned types are not committed by accident (eg .obj, .pdb). Well, not since the first time someone checked in 2 gig of compiler-generated temporary files :(
for windows:
@echo off
svnlook log -t "%2" "%1" | c:\tools\grep -c "[a-zA-z0-9]" > nul
if %ERRORLEVEL% NEQ 1 goto DISALLOWED
echo Please enter a check-in comment 1>&2
exit 1
:DISALLOWED
svnlook changed -t %2 %1 > c:\temp\pre-commit.txt
findstr /G:"%1\hooks\ignore-matches.txt" c:\temp\pre-commit.txt > c:\temp\precommit-bad.txt
if %ERRORLEVEL% NEQ 0 exit /b 0
echo disallowed file extension >> c:\temp\precommit-bad.txt
type c:\temp\precommit-bad.txt 1>&2
exit 1
-
3
-
4I'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) – gbjbaanb Nov 26 '09 at 22:41
I use a post-commit hook to rewrite the author property to a friendly name from our ldap tree. (authentication is with employee id)
A great commit hook we have at on our archive is to check all .VCPROJ (or .CSPROJ) visual studio projects to make sure the output directories weren't changed to anything local (commonly used for debugging).
These problems will compile properly but still break the build because of missing executables.

- 2,487
- 2
- 27
- 55
In the company I currently work on, this is checked:
- If binary files have the needs lock attribute set;
- If the Java files have the standard copyright notice and if it includes the current year;
- If the code is properly formatted (we use Jalopy for code formatting) - this may sound silly but it actually makes text comparisons between different versions easier;
- If the code has a commit message;
- If the directory structure conforms to what is defined (all projects should be under a defined SVN folder, and each project should have a tags, branch and trunk folder);
I guess that's it.
I like the idea of checking if the commit is associated with a ticket; it actually makes a lot of sense to me.

- 8,368
- 4
- 28
- 28

- 10,416
- 2
- 25
- 34
Some prefer running a lint-like tool for a given language to find common problems in the code and/or enforce coding style. However in a small and skilled team I prefer to allow every commit to go through and deal with possible problems during continuous integration and/or code review. Thanks to this commits are faster which encourages more frequent commits, leading to easier integration.

- 12,011
- 2
- 32
- 32
-
Check that there are no mixed tabs/spaces in indentation could be a good thing though. Softer than a full LINT, but still useful. – Macke Jun 08 '12 at 17:57
I use the check-mime-type.pl pre-commit hook to check that MIME Type and End of line options are set on committed files. I use subversion to publish files to be visible on a website using DAV, and all files without the MIME Type set get served as text files (e.g. HTML source gets displayed in a browser instead of the rendered markup).

- 1,908
- 3
- 18
- 30
-
check-mime-type.pl is now: https://svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/check-mime-type.pl – Malcolm Mar 20 '14 at 21:37
That it has a commit message, and it is != than "bug fixing". Damn, did I hate those useless messages!

- 1,216
- 11
- 23
We use a pre-commit and post-commit hook combo to automatically update bugzilla with the associated entry from the svn commit.
We use a second (pre-commit) hook to ensure that the appropriate svn:eol-style and svn:keywords properties are set on a file before it is added to the repostitory.
We have a third (post-commit) hook to kick off a build and mail the results if the build is broken, and to inform everyone when the build has been fixed again.
We have a fourth (post-commit) hook to kick off svn replication, to ensure that the offsite replication is as up to date as possible.
Unfortunately, I cannot post the source to these, but, except for the Bugzilla integration, they are easy enough to implement, and Hudson is probably a better choice for continuous integration.
For bugzilla integration, I would suggest looking at scmbug.

- 27,756
- 10
- 52
- 74
I use the following hook script to make sure line endings of source code and permissions of shell scripts are correct (it is frustrating when someone checks in on windows when everything seems ok and breaks the unix build).
#!/bin/bash
REPOS="$1"
TXN="$2"
# Exit on all errors.
set -e
SVNLOOK=svnlook
echo "`$SVNLOOK changed -t "$TXN" "$REPOS"`" | while read REPOS_PATH
do
if [[ $REPOS_PATH =~ A[[:blank:]]{3}(.*)\.(sh|c|h|cpp) ]]
then
if [ ${#BASH_REMATCH[*]} -ge 2 ]
then
FILENAME=${BASH_REMATCH[1]}.${BASH_REMATCH[2]};
# Make sure shell scripts are executable
if [[ sh == ${BASH_REMATCH[2]} ]]
then
EX_VALUE="true"
if [ -z "`$SVNLOOK propget -t \"$TXN\" \"$REPOS\" svn:executable \"$FILENAME\" 2> /dev/null`" ]
then
ERROR=1;
echo "svn ps svn:executable $EX_VALUE \"$FILENAME\"" >&2
fi
EOL_STYLE="LF"
else
EOL_STYLE="native"
fi
# Make sure every file has the right svn:eol-style property set
if [ $EOL_STYLE != "`$SVNLOOK propget -t \"$TXN\" \"$REPOS\" svn:eol-style \"$FILENAME\" 2> /dev/null`" ]
then
ERROR=1;
echo "svn ps svn:eol-style $EOL_STYLE \"$FILENAME\"" >&2
fi
fi
fi
test -z $ERROR || (echo "Please execute above commands to correct svn property settings." >& 2; exit 1)
done

- 373
- 2
- 8
Insert a note into Mantis bugtracker with the changelist details based on the commit message having 'issue #' or the like via RegEx.

- 28,537
- 15
- 60
- 73
How about a hook to compile the project? e.g. Run make all. This ensures no one checks in code that doesn't compile! :)

- 2,212
- 1
- 16
- 18
-
What if the build takes 5-10 minutes? I'm intrigued, but it seems difficult. – Macke Dec 01 '09 at 20:39
-
likely better off doing some kind of lint checking instead, then using http://cruisecontrol.sourceforge.net/ or something to handle the builds – Jason Jan 06 '10 at 23:06
-
7
-
2I 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. – iuiz Nov 22 '10 at 15:04
I'd enjoy a hook that checks for [Reviewer: xyz] note in the commit message, and rejects the commit.

- 18,794
- 5
- 57
- 67
I'm thinking about writing one to check doctype's on aspx / html files, just to make sure everyone is using the correct one.
Also, you can have a pre (or post) commit hook push a notification out to your CI server as described on the Hudson Blog

- 19,068
- 14
- 83
- 115
I check for case collision (stupid windows) and also require-mergeinfo.pl to ensure that the client is at least 1.5 - that way svn:mergeinfo will always be set

- 7,668
- 1
- 36
- 61