O.K. I have Subversion and Bugzilla sharing accounts (see here) and I have WebSVN allowing only authorized users to browse the repository (see here).  Now I would like to be able to link a Subversion commit to a Bugzilla bug.

Ideally, when I do a commit, I would like my GUI tool to include a "Bug ID" text field to enter in bug numbers. I’d like the bug numbers to be added to the commit log message in a standard way, and I’d like the specified bug to be updated in Bugzilla to indicate the modified files.

I was able to accomplish all these things with the BugTraq properties (and tools that support BugTraq like TortoiseSVN and Subclipse) and the ScmBug integration service.

BugTraq

Before I start talking about BugTraq properties, here is a quick introduction to Subversion properties in general. Subversion properties are "metadata" that you can attach to versioned files and directories. This metadata (name-value pairs) is primarily intended to be used as processing directives by client applications. Subversion itself defines some properties, such as the "svn:eol-style", which is used to specify that you want a file to be converted to a specific "end of line style" (like CRLF) when a new version is committed.

BugTraq are a set of properties for a standardized way of integrating Subversion clients and third party bug tracking software. The original spec can be found at:
http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/doc/issuetrackers.txt
(You’ll be prompted for user id and password, use "guest" with no password)

The main property is "bugtraq:message". This property serves two purposes:

1. The fact that this property is set should trigger the client to prompt for a bug id when committing.
2. The bug id is added to the commit log message using the format specified.

I have "bugtraq:message" set to something like "Issue: %BUGID%", where the %BUGID% field is how you specify where the bug id is to be inserted. Both TortoiseSVN and Subclipse honor the "bugtraq:message" property so, when you do a commit in one of these tools, a new text field for the Bug ID just "magically" shows up in the GUI. If you enter in a value, your commit log message has "Issue: bug_id" appended to it.

The other property that I’m using is "bugtraq:url" where you specify a format to create a URL. This is used by a client to create a hyperlink back to the bug tracking system.

I have the "bugtraq:url" property set to
"http://my.server.com/bugzilla/show_bug.cgi?id=%BUGID%".
WebSVN honors this BugTraq property so, when I view a commit message that has the "Issue: bug_id" appended to it, WebSVN displays the bug id value as a hyperlink back to Bugzilla.

So, with BugTraq, I now have a way of specifying a Bug ID when I commit and that bug id is placed in the commit message in a standard way. But Bugzilla still doesn’t know anything about it. That’s where ScmBug comes in.

ScmBug

The ScmBug project (http://www.mkgnu.net/?q=scmbug) aims to create a generic bridge between Software Content Management (SCM) systems and Bug tracking systems. It currently supports CVS and Subversion on the SCM side, and Bugzilla and Mantis on the Bug tracker side.

There are two parts to ScmBug:

1. Event hook scripts that integrate into the SCM (referred to as "glue").
2. A server process that integrates with the bug tracking system.

ScmBug uses a Subversion "pre-commit" hook to parses the commit log message looking for any Bug IDs. In order for this to work, the commit log message has to be formatted in standard way (and thanks to BugTraq, it is!) When it finds a Bug ID, it connects to the server process and passes the Bug ID and commit information.

The server process then updates Bugzilla with the given information. It does this by calling some of the perl scripts in the Bugzilla installation directory.  This means that the server process has to be on the same machine as Bugzilla.

I’m running Bugzilla on Fedora Core 5, so I used the ScmBug RPMs to install. They put a "scmbug-server" start script in "/etc/init.d".
You have to tweak the "daemon.conf" file in "/etc/scmbug" to tell it where to find Bugzilla before starting the server.

Next, you have to install the "Glue" (the Subversion hooks). ScmBug comes with a command line tool called "scmbug_install_glue" to help with this (see the ScmBug documentation on how to run it).

After this, you have to tweak the "glue.conf" file which will be located in the "hooks/etc/scmbug" directory in your Subversion repository.

The primary things you need to change in the "glue.conf" file are the regular expressions used to parse Bug IDs. Since my "bugtraq:message" = "Issue: %BUGID%", I found that the following settings work:


bugid_regex => ‘.*Issue:\s*(.*?)$’,
bugid_split_regex => ‘,\s+#|\s+#|,|\s+’,
log_regex => ‘^(([^\r\n]|[\r\n])*)Issue:.*$’


I also changed the "presence_of_bug_ids" property to "optional", otherwise you wouldn’t be able to do a commit without a bug id. I also disable the "minimum_log_message_size" enforcement.

Gotchas!

I ran into a few problems along the way while trying to make this work. Here are some things to keep in mind...

• The BugTraq properties are set on a directory, and clients will apply the BugTraq property to any child directories. So if you set the BugTraq property on the directory that is at the root of the repository, then any commit to a sub directory (trunk, branches, tags, etc) will have the Bug ID text box.
• The directory you check out must have BugTraq properties set! It is uncommon to check out an entire repository. Usually you only check out the trunk or a particular branch. In this case, the BugTraq properties must be set on the directory you checked out. The client will not propagate the BugTraq properties from the parent directory because, since you didn’t check it out, the client doesn’t know anything about it. What I did was set the properties at the root of the repository using TortoiseSVN and used the "recursive" check box to have the properties also set on the trunk and branches.
• I had problems with SELinux and ScmBug. Access to my Subversion is through Apache so, when you do a commit, svn is called from the httpd process. This commit process subsequently tries to make a network connection to the ScmBug server process which kept failing for me. I never fully figured out why, but I made a guess that it had to do with Fedora and SELinux. I ended up disabling SELinux, and everything worked fine after that.
• I had problems with ScmBug and the combination of Subclipse and Subversion 1.2. If I entered a multi line comment, ScmBug would return an error. This actually turned out to be due to the "svnlook" command and its inability to handle comments with a mix of end-of-line styles. The svnlook problem is fixed in Subversion 1.3
• Don’t forget to tweak the "glue.conf" file! Modify those regular expressions, and you probably want to "relax" some of the enforcement rules that ScmBug provides.
• The smbug-server process is not secure (anyone can connect to it). I run Subversion and Bugzilla on the same machine and use a firewall to at least make sure that only local processes can access it. (This issue is on the ScmBug developers "TODO" list).