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

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

Answer 2

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 3

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

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

Answer 6

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.