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

W

22

40

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

Wench answered 19/5, 2009 at 19:31 Comment(6)

one that fails for a specific user on even numbered days of the month? – Gabon 19/5, 2009 at 19:32

"The question you are asking appears to be subjective and is likely to be closed." – Donnie 19/5, 2009 at 19:33

Should this be a community wiki? it is subjective, and doesn't ask to solve a particular problem. – Gatias 19/5, 2009 at 19:35

I think it could be edited to actually be useful, but in its current incarnation should be closed. – Tubule 19/5, 2009 at 19:36

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) – Dorman 19/5, 2009 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. – Donnie 19/5, 2009 at 19:52

P

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.

Prophet answered 19/5, 2009 at 19:31 Comment(1)

Email is so two thousand and late... – Jinn 19/11, 2014 at 20:21

C

45

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

Chellman answered 19/5, 2009 at 19:33 Comment(10)

Why would this get a down vote? – Tubule 19/5, 2009 at 19:37

Probably by someone who doesn't like leaving comments! ;) – Teetotum 19/5, 2009 at 19:53

Yeah great, non constructive feedback ! – Chellman 19/5, 2009 at 19:59

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. – Charmaincharmaine 19/5, 2009 at 20:33

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. – Tubule 19/5, 2009 at 21:9

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. – Sciomachy 19/11, 2009 at 22:43

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. – Beaufort 22/11, 2009 at 22:11

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... – Chellman 22/11, 2009 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. – Beaufort 23/11, 2009 at 1:35

My tracker tracks bug as well as features... – Slam 23/11, 2009 at 21:14

C

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.

Charmaincharmaine answered 19/5, 2009 at 19:31 Comment(2)

Never thought about to solve this problem by pre-commit... – Wench 19/5, 2009 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. – Charmaincharmaine 19/5, 2009 at 20:31

F

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

Frenulum answered 19/5, 2009 at 19:34 Comment(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); – Errol 12/3, 2010 at 14:49

B

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.

Brigadier answered 19/5, 2009 at 19:34 Comment(5)

Check for tabs? What do you mean? – Pectase 13/5, 2011 at 7:19

@Pectase - 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. – Seema 23/5, 2011 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. :) – Brigadier 1/9, 2011 at 2:47

"Check for tabs and reject the check-in" could you share this one? – Sherborn 28/8, 2015 at 14:34

Heh, that was years ago. I don't have it handy anymore. – Brigadier 28/8, 2015 at 14:49

L

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/

Lemmie answered 19/5, 2009 at 19:31 Comment(1)

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-system/… – Contrive 19/1, 2012 at 12:28

P

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.

Prophet answered 19/5, 2009 at 19:31 Comment(1)

Email is so two thousand and late... – Jinn 19/11, 2014 at 20:21

T

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

Teetotum answered 19/5, 2009 at 19:35 Comment(0)

S

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

Satanism answered 19/5, 2009 at 19:31 Comment(2)

actually this should be done in svn:ignore not in a pre-commit hook. – Preceptive 24/11, 2009 at 21:17

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) – Satanism 26/11, 2009 at 22:41

G

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.

Gallenz answered 19/5, 2009 at 19:31 Comment(0)

T

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.

Trackless answered 19/5, 2009 at 19:31 Comment(0)

E

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)

Evoy answered 19/5, 2009 at 19:31 Comment(0)

N

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.

Nectarine answered 19/5, 2009 at 19:31 Comment(1)

Check that there are no mixed tabs/spaces in indentation could be a good thing though. Softer than a full LINT, but still useful. – Charmaincharmaine 8/6, 2012 at 17:57

E

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

Euhemerize answered 19/5, 2009 at 19:31 Comment(1)

check-mime-type.pl is now: svn.apache.org/repos/asf/subversion/trunk/contrib/hook-scripts/… – Brigidabrigit 20/3, 2014 at 21:37

G

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

Gerge answered 19/5, 2009 at 19:31 Comment(0)

J

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.

Jaggers answered 19/5, 2009 at 19:31 Comment(0)

P

2

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

Possible answered 19/5, 2009 at 19:31 Comment(0)

C

2

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

Conlon answered 19/5, 2009 at 19:31 Comment(1)

That's not pre-commit but post-commit. – Charmaincharmaine 19/5, 2009 at 20:33

J

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! :)

Jobey answered 19/5, 2009 at 19:31 Comment(4)

What if the build takes 5-10 minutes? I'm intrigued, but it seems difficult. – Charmaincharmaine 1/12, 2009 at 20:39

likely better off doing some kind of lint checking instead, then using cruisecontrol.sourceforge.net or something to handle the builds – Crabby 6/1, 2010 at 23:6

Thats what a ci server is for... – Duester 2/2, 2010 at 15:50

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. – Drusy 22/11, 2010 at 15:4

V

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

Vitric answered 19/5, 2009 at 19:31 Comment(0)

P

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

Plummet answered 19/5, 2009 at 19:31 Comment(0)

D

0

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

Recommended topics

Hot tags