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.
The checks
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.
The implementation
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:
svn://kore-nordmann.de/php-commit-hooksI also configured a mailing list for the discussion and future deveopment of those standards – you can subscribe at pch-subscribe@kore-nordmann.de (the ML itself resides under pch@kore-nordmann.de).
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. :)
Comments
Fields with bold names are mandatory.
Paul at Wed, 23 Sep 2009 18:49:29 +0200
Hello,
Link to commentThis project looks interesting. Can you please contrast it with what can be accomplished using a Continuous Integration server such as Xinc (http://xinc.googlecode.com)?
Thanks!
Paul
Basilio Vera at Tue, 29 Sep 2009 13:18:50 +0200
Paul, with this hooks you can forbid commits, with a CI server you are able to use the same rules once have been accepted in the repository, and here's a subtle difference... With several developers it's very common to have a lot of code in repository that violates the rules. ;)
Link to commentIn our company we are even using Pre-Commit Client hooks (feature providen by TortoiseSVN) to check if the UnitTesting is good enough (min asserts number, code coverage of 70%) to every class you are trying to commit. ;)