What kinds of hook scripts are people using for Subversion? Just general ideas but code would be great too!
16 Answers
I am using the pre-revprop-change hook that allows me to actually go back and edit comments and such information after the commit has been performed. This is very useful if there is missing/erroneous information in the commit comments.
Here I post a pre-revprop-change.bat batch file for Windows NT or later. You
can certainly enhance it with more modifications. You can also derive a
post-revprop-change.cmd from it to back up the old snv:log somewhere or just to append it to the new log.
The only tricky part was to be able to actually parse the stdin from
the batch file. This is done here with the FIND.EXE command.
The other thing is that I have had reports from other users of issues with the use of the /b with the exit command. You may just need to remove that /b in your specific application if error cases do not behave well.
@ECHO OFF
set repos=%1
set rev=%2
set user=%3
set propname=%4
set action=%5
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Only allow changes to svn:log. The author, date and other revision
:: properties cannot be changed
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
if /I not '%propname%'=='svn:log' goto ERROR_PROPNAME
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Only allow modifications to svn:log (no addition/overwrite or deletion)
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
if /I not '%action%'=='M' goto ERROR_ACTION
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: Make sure that the new svn:log message contains some text.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
set bIsEmpty=true
for /f "tokens=*" %%g in ('find /V ""') do (
set bIsEmpty=false
)
if '%bIsEmpty%'=='true' goto ERROR_EMPTY
goto :eof
:ERROR_EMPTY
echo Empty svn:log properties are not allowed. >&2
goto ERROR_EXIT
:ERROR_PROPNAME
echo Only changes to svn:log revision properties are allowed. >&2
goto ERROR_EXIT
:ERROR_ACTION
echo Only modifications to svn:log revision properties are allowed. >&2
goto ERROR_EXIT
:ERROR_EXIT
exit /b 1
If you have a mix of unix and Windows users working with the repository, I urge you to use the case-insensitive.py pre-commit hook-script as a precautionary measure. It prevents hard-to-sort-out situations where svn updates fail for Windows users because of a file rename which only changed the case of the file name. Believe me, there is a good chance it will save you trouble.
We use FogBugz for bug tracking, it provides subversion commit scripts that allow you to include a case number in your check in comments and then associates the bug with the check in that fixed it. It does require a WebSVN instance to be set up so that you have a web based viewer for your repository.
In my work place we've set up a post-commit hook that generates RSS feeds that are displayed in various dash boards and are used for code reviewers to know when it is time to review and for us to see that new employees are committing enough.
several things we use them for:
- integrating with the bug tracker (Trac in our case - a commit message that says 'Closes #514' automatically marks that bug as closed
- integrating with the build integration (buildbot in our case - a commit to a watched branch triggers a build
- pre-commit hook for validating the commit - we use svnchecker. It validates our Python code for PEP8 correctness
- sending checkin mails to a mailing list
- running indentation scripts
I'm using post-commit hooks (I think it's this one) to post a message to a forum on Basecamp for each commit. Two advantages:
As the lead developer, I get a roll-up of commits every morning (via the RSS feed from that basecamp forum) and can see what my team has been up to pretty quickly.
Our Trac/SVN install is behind our firewall, so this gives my higher-ups in other locations a window into what we're doing. They might not understand it, but to a manager a lot of activity looks like, well, a lot of activity ;)
I guess the end result of this is similar to what @Aviv is doing.
I'm looking into solutions for building the latest commit on a separate server for continuous integration, but I'm going to have to change the way we make changes to our database schema before that will work.
This was discussed on the subversion users mailing list a while ago. This post in particular has some useful ideas.
The most common one I think is to allow people to change revision comments after comitting.
You need to enable the 'pre-revprop-change' hook script to allow that. The example provided, if enabled allows editing only the comment property and only be the original comitter. Great for correcting typos.
A hook to notify the bug/issue management system of changes to repository. Ie. the commit message has issue:546 or similar tag in it that is parsed and fed to the bug management system.
We check the following with our hook scripts:
- That a commit log message has been supplied
- That a reviewer has been specified for the commit
- That no automatically generated code or banned file types land up in the repository
- Send an email out when a branch / tag is created
We still want to implement the following:
- Send an email when a user acquires a lock on a file
- Send an email when your lock has been stolen
- Send an email to everyone when a revision property has been changed
We use a commit hook script to trigger our release robot. Writing new release information to a file named changes.txt in our different products will trigger the creation of a tag and the relevant artifacts.
I have one setup using the Ruby Tinder library that I send to a campfire room, if anyone wants the script I can post or send the code to you.
Other common ones I've seen are posts to bug tracking systems and email notifications.
Related