I have been playing with connecting up the source code repository (CVS) and my issue/bug tracking tool (Mantis). The aim of all this is some transparency in relation to what changes were related to which ite,s of development and vice versa.
See it would be good to be able to say, this file has had 3 recent commits, all in different parts, and then work out what they changes were attempting to do. I know that commit comments are supposed to do this, but some times its better to have the detailed bug report to read the overall aim.
Also, the ability to collate a change log from a set of data changes and show which bugs have been worked on, resolved, etc.
So I started looking at what configuration I could use to get this integration. I was looking for some sort of control of the bug tracking tool via the cvs commit. I know that you can do things like verify code styles, and such via the one of the cvs commit hook scripts. I have a plugin to the script that allows emails to be sent upon commit.
So I started googling for scripts that could do this, there were a few around but were either old, or didn’t support my CVS–>Mantis combination.
Then gold, a project called SCMBUG.. Exactly what I was looking for, integration between a source control management system and a bug tracking tool. Even better was that it was a generic framework, that allowed plugins for different applications.
On the list of supported SCM’s was CVS (obviously), and on the list of supports Bug tools was Mantis.. YAY.
So a few hours later, its installed and configured. Works well, infact a bit too well. I have it enforcing that ANY commit to CVS must have a bug associated to it, and that the bug must be open, and it must be assigned to me. You see all of these settings are configurable via it, and I thought I’d force myself to use it in nearly it’s harshest configuration.
The only problem is that I now realise that I do a lot of random commits, fixing things that technically not bugs, or at least they are not filed as bugs. But under this new regime they are not allowed. So its off to Mantis to log a bug about the small change, then the commit.
I’m hoping after a while I’ll get into the pattern of logging bugs, then fixing them. Here’s hoping.
So after this review, I need to get some technicals into this document, as it will be my first reference when I forget how things actually work. In reality I installed SCMBug about 6 weeks ago, its only now that I had to make a change and forgot what it is that I realised I should have blogged it.
So here goes.
The installation of SCMBUG modifies the settings in the CVSROOT folder to setup pass through of the commits to the SCMBUG-server, this server needs to be started before any commits will actually be allowed.
Settings for how the SCMBUG server treats the commits are also in the CVSROOT directory, under the etc/scmbug directory. The file glue.conf should be checked out of CVS, edited and uploaded.
I think from memory the SCMBUG-server needs to be restarted for the changes to take effect, although to be honest I just edited the glue.conf file direct on the CVS server, not doing the checkout/in process.
In all it works well, when I commit I just need to add something like:
bug 22: Changed the way the login creates cookies
status 22: resolved fixed
The first line says add a log comment to bug 22, and record the changes.
The second line is to actually progress the workflow of the bug in Mantis, by resolving the bug 22 with a status of fixed.
Works well, any other updates will be posted to the site.
steve | 
07 17th, 2008| 