As a software developer, I love version control, and I love bug tracking systems. I honestly don’t know how anyone got any work done without them. I’ve got Subversion set up with a post-commit hook that reports my commits to FogBugz. This enables FogBugz to keep track of which code changes are associated with each issue. If, a year from now, I want to go back and see exactly which changes I made to fix a certain bug, FogBugz has that information. It’s really cool.

But, as usual, there’s a catch. I also use svnmerge to keep track of changes between branches. It makes it trivial to merge changes from the trunk to a release branch, or vice versa. When you merge changes from one branch to another, svnmerge makes a nice file with the descriptions of each change included in that merge so that you can use it as the log message when you commit the changes associated with the merge.

What I’ve just realized is that my post-commit hook is finding all the references to bugs in that message and updating each of the bugs in FogBugz with a link to the commit associated with the merge. This has two effects. One, it causes the commit to take a really, really long time. (The post-commit script calls FogBugz once for every bug reference in the commit message.) And the other is that now every bug referenced in the merge is going to have a link to this giant commit that’s not really associated with any of them.

Sometimes all of your brilliant individual ideas combine to produce a bad outcome. In the future I won’t be using the commit message that svnmerge provides.