SVN commit hooks
First published at Wednesday, 16 September 2009
Warning: This blog post is more then 14 years old – read and use with care.
SVN commit hooks
Thomas moderated a discussion during the PHP-Unconference-Hamburg on SVN commit hooks. It showed that there is interest in my commit message parser, so that I make it available now under New-BSD-license.
I created a SVN repository which contains the commit message parser, a lint checker and the basic infrastructure for more commit hooks, with the discussed reporting facilities.
The basic idea
The basic idea is to ensure that all developers in your team follow certain standards, when contributing code to your project. In some cases some developers continue to write code which does not follow your coding standards, sometimes even accidentally commit code, which does not compile, or do not pay enough attention to their commit messages.
One way to keep your developers thinking about this are commit hooks, for example in SVN, which reject commits which do not follow the defined standards, or inform the developer itself, the project manager, or some public list about violations in a recent commit.
There are several possible checks, which have been developed and proved valuable in different projects:
Simple lint checking
It ensures that the committed files actually compile. This should be a hard criteria for accepting commits, as this might break the checkouts of all other developers and thus decrease the productivity.
Commit message verification
For arbit I implemented a validator for commit messages, which ensures the commit messages follow a defined standard. This not only ensures the commit messages are parseable later on, but also causes the developers paying more attention to the contents of their commit messages. It showed that such checks can noticeably increase the quality of commit messages in projects.
Code sniffer checks
Code sniffer can ensure that your code follows your coding standards, each method is documented, and so on. It is arguable if you want to prevent code from being committed if it does not follow the coding standards, but I think you should at least inform the developer in a post-commit-hook.
After the discussion on the unconf I quickly hacked together the basic infrastructure for such checks, so that it fulfills the following goals:
Checks should be pluggable and easily configurable
The checks should be possible to configure for pre-commit and post-commit hooks.
For proper reporting on post- and pre-commit-hooks it should be possible to configure the reporting accordingly to either send mails, or echo the errors to STDOUT for pre-commit-hooks – with future possible custom reporters, of course.
The code is available in the following SVN repository, including tests:
Please test the yet available stuff and join a discussion on the mailing list. This is at a very early stage of publishing, but I am sure you can deal with that. :)