Catching Subversion conflicts on commit

If two people work on the same file in the same place in the file, Subversion can get a bit confused about how to merge the two different pieces, and will prompt the user to help it sort things out. However, it is up to the user to actually do so, and they're perfectly able to try to submit that file with the conflict markers still in the file. This is a pre-submit hook to not let people shoot themselves (and your codebase) in the foot.

Avoiding PHP syntax errors with Subversion pre-commit hooks

Since my last few posts have all been about Subversion, I figured I'd do another. Our new team member is an experienced programmer, but has not had any experience with PHP. And he's not real good about actually running his code before submitting it.

PHP allows you to run its command line executable with a -l flag to catch any syntax errors in your code. Very simple, but can really help catch some stupid errors. Yes, they should definitely be caught by a code review, but code reviewers should also be able to assume that the code actually runs.

So here's a Subversion pre-commit hook that will run PHP lint on all PHP files and reject the commit if any of them fail.

Integrating Subversion and Review Board

At Google, all production code must be peer reviewed before it is allowed to be submitted to their source control system. Since I'm no longer a Googler, I don't have access to their awesome infrastructure so I had to roll my own. Review Board is a pretty good code review system, and unlike the open source implementation of Google's internal one, you can host Review Board on your own hardware.

We use Subversion as our SCM. Out of the box, Subversion doesn't force code to be reviewed before submission, and I couldn't find any documentation about forcing code reviews through pre-submit hooks. Subversion's hooks are pretty powerful, and Review Board has a decent API, so I wrote my own. Hopefully this is useful to someone out there. It's written in PHP5. Put this in your subversion hooks directory, call it pre-submit, and make it executable.

Forcing PHPUnit tests on Subversion commit

All of my PHP projects use PHPUnit for unit testing. One of my coworkers just refuses to understand the point of testing. He doesn't get Test Driven Development (TDD), and rarely runs the unit tests for his classes. This means that he frequently breaks my build. I can't force him to change his behavior since he doesn't work for me, but I can change the way my systems work. And I control the Subversion server.
I wanted to force unit tests to pass before allowing submission, but couldn't find anything about running PHPUnit tests in a Subversion pre-commit hook. So I wrote my own. Hopefully this will help someone out there:
To use this, copy it to the hooks directory in your Subversion repository and name it 'pre-commit'. Make sure the paths defined in the script are correct for your system. Make it executable (chmod +x pre-commit).

Setting up bug tracker regexes in WebSVN

A while ago I set up WebSvn (http://www.websvn.info/) to allow viewing my Subversion repository at work. Today I decided to make it hack the commit messages in order to change bug links into hyperlinks to my bug tracker. After looking at the code a bit, there was a configuration option to turn on 'bugtraq' which claims to do what I want, but the documentation on how to set it all up was a bit non-existent. This post is mainly for me to remember how to set this up at any future employer that I might need it at.

To enable the log message hacking, edit include/config.php and set "$config->setBugtraqEnabled(true);". This will turn on the code that tries to parse log messages for all repositories that you've got set up. If you want to turn it on for a subset of your repositories you can add lines like "$config->setBugtraqEnabled(true, 'repository-name');" or turn them off the same way.

However, there doesn't appear to be documentation there about actually configuring where the links should go, or how you format the bug labels in your commit messages. My commit messages for the current project have used many different bug labels throughout its history:

• bug: 12
• bugs: 12, 34
• Fixed lots of bugs (bugs: 12, 34)
• Issue #12

It would be nice to catch them all.

After Googling for some information about how to set all this up, I realized that WebSVN uses Subversion properties for configuring the regexes needed instead of putting them in the config file with the rest of the repository configuration. Here's the subversion commands I used to set up the log munging to link to my bug tracking system:

$ svn propset bugtraq:logregex '(([Bb]ug[s]?)|([Ii]ssue))+[:]? [#]?(\d+)(?:,? ?#?(\d+))*

(\d+)' file:///opt/svn/my_repo

$ svn propset bugtraq:url http://tracker.domain.com/show_bug.cgi?id=%BUGID% file:///opt/svn/my_repo

Note that the first one spans a line. WebSVN uses the first line to find the bugs list, and the second one to find individual bug numbers from within the larger list. %BUGID% will be replaced in the URL with the bug id.

Also note that if you use the typical trunk, branches, tags setup, you can not just set the properties in the root of your source tree if you have trunk checked out. It needs to be set at the root of the repository or it will not work.

Hopefully this will save someone some time trying to set up the log munging without losing too much hair.