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+))*
$ 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.