40

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

bahrep
  • 29,961
  • 12
  • 103
  • 150
powtac
  • 40,542
  • 28
  • 115
  • 170
  • 15
    one 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
  • 2
    Indeed 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 Answers22

45

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

Jonathan Holloway
  • 62,090
  • 32
  • 125
  • 150
  • 2
    Why would this get a down vote? – Instantsoup May 19 '09 at 19:37
  • 13
    Probably by someone who doesn't like leaving comments! ;) – John Feminella May 19 '09 at 19:53
  • 1
    Yeah great, non constructive feedback ! – Jonathan Holloway May 19 '09 at 19:59
  • 3
    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. – Macke May 19 '09 at 20:33
  • 7
    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. – 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
  • 1
    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. – San Jacinto Nov 22 '09 at 22:11
  • 1
    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... – 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
  • My tracker tracks bug as well as features... – Vinko Vrsalovic Nov 23 '09 at 21:14
20

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.

Macke
  • 24,812
  • 7
  • 82
  • 118
  • Never thought about to solve this problem by pre-commit... – powtac May 19 '09 at 20:16
  • 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
13

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...

Ben S
  • 68,394
  • 30
  • 171
  • 212
  • 1
    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); – sleep-er Mar 12 '10 at 14:49
13
  • 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.
i_am_jorf
  • 53,608
  • 15
  • 131
  • 222
  • Check for tabs? What do you mean? – demoncodemonkey May 13 '11 at 07:19
  • 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
    "Check for tabs and reject the check-in" could you share this one? – jpo38 Aug 28 '15 at 14:34
  • Heh, that was years ago. I don't have it handy anymore. – i_am_jorf Aug 28 '15 at 14:49
11

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/

Christian K.
  • 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
8

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.

fitzgeraldsteele
  • 4,547
  • 3
  • 24
  • 25
8

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
John Feminella
  • 303,634
  • 46
  • 339
  • 357
7

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
Dónal
  • 185,044
  • 174
  • 569
  • 824
gbjbaanb
  • 51,617
  • 12
  • 104
  • 148
  • 3
    actually this should be done in svn:ignore not in a pre-commit hook. –  Nov 24 '09 at 21:17
  • 4
    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) – gbjbaanb Nov 26 '09 at 22:41
6

I use a post-commit hook to rewrite the author property to a friendly name from our ldap tree. (authentication is with employee id)

6

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.

greggorob64
  • 2,487
  • 2
  • 27
  • 55
6

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.

eswald
  • 8,368
  • 4
  • 28
  • 28
Ravi Wallau
  • 10,416
  • 2
  • 25
  • 34
5

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.

Adam Byrtek
  • 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
3

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).

Eric Bréchemier
  • 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
2

That it has a commit message, and it is != than "bug fixing". Damn, did I hate those useless messages!

Victor Jalencas
  • 1,216
  • 11
  • 23
2

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.

Paul Wagland
  • 27,756
  • 10
  • 52
  • 74
2

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
wdk
  • 373
  • 2
  • 8
2

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

Adam
  • 28,537
  • 15
  • 60
  • 73
1

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

tchen
  • 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
    Thats what a ci server is for... – André Feb 02 '10 at 15:50
  • 2
    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. – iuiz Nov 22 '10 at 15:04
0

Solving lack of File Externals in SVN 1.5 using PostUpdate and PreCommit

Azlam
  • 2,052
  • 3
  • 24
  • 28
0

I'd enjoy a hook that checks for [Reviewer: xyz] note in the commit message, and rejects the commit.

Pavel Radzivilovsky
  • 18,794
  • 5
  • 57
  • 67
0

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

Allen Rice
  • 19,068
  • 14
  • 83
  • 115
0

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

thekbb
  • 7,668
  • 1
  • 36
  • 61