Share common / useful SVN pre-commit hooks [closed]

Question

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

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

Answer 2

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

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

Answer 4

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

Answer 5

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

Answer 6

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/

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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

Answer 14

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

Answer 15

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

Answer 16

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.

Answer 17

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

Answer 18

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

Answer 19

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

Answer 20

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

Answer 21

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

Answer 22

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