Integrating Subversion (SVN) with Bugzilla

It’s well documented why using a source code control system is a worthwhile investment. Change tracking, team working, a safety-net, release management, control and reporting. And Subversion, a.k.a. svn, is the leading light in the open source world, taking over the mantle from CVS.

Subversion is different. It takes a different approach to any other source code control system I know. It uses lightweight ‘copy’ operations to achieve tagging and branching. It’s intuitive. If you didn’t have source code control and you had a code base that you wanted to keep as “version 1″, you’d most likely take a copy of the directory and call the new directory “version 1″. Well that’s tagging in svn.

But, like I say, this is all well-documented.

Bugzilla is a bug-tracking system. I hate the word “bug-tracking”. (I’m not very fond of the word “bug” at all!) But it’s a misnomer to label it a bug-tracking system because it tracks any sort task – typically a programming task. Frequently, it tracks the tasks involved in developing new products and new features. Not just bug-fixes. So I prefer task-tracker.

Bugzilla is a perl-based open-source task-tracker. It’s been around for years and with each release (especially the recent 3.x stream, which introduces custom fields, at last) it gets better and better, It’s basic. It lets you record a bunch of information relating to a task. A summary. The priority of the task. Who is interested in getting updates. The status.

10 years ago, when working at Thomson Datastream, we used Paradox to keep track of our tasks. It was implemented as a form-based database. Bugzilla is no different. Each task has an ID and associated with that ID are the fields.

It has some nifty additional features to facilitate workflow. When a “bug” is updated (don’t get me started on how wrong the grammar and accuracy of that phrase is), interested parties are emailed to be told what’s changed. It has a flexible reporting system. It has some basic project management facilities, such as task estimate and time tracking. But it’s still essentially just a bunch of fields in a database.

I often hear people confusing source code control with task-tracking. They are very different. One is concerned with the lines of code being written and managing the history of changes. The other is concerned (typically) with recording and managing the programming tasks.

And in any semi-mature development environment, both are needed. Especially where a team is working together. But even as a one-man team, I’d recommend the use of both.

That doesn’t sound too controversial, but it is. And here’s why. When a developer checks some code into svn, that change is given a unique “revision number”. The coder can provide a description of their change when they commit. And svn supports “hook scripts” which easily allow it to be configured to send emails when code is committed (or tags created or branches merged, etc.) And so the argument often goes: why bother with a task-tracking system too, when I’m getting most of the functionality with just Subversion?

The problem is this. Programmers are concerned with the nuts and bolts of development. Their change descriptions are likely to read, “Change the user array to be an array of objects instead of id’s”, or “Add new sort function”, or “Implement new View module for the admin n Controller”. But a project/product/commercial manager – or, perhaps much more prescient, a customer or prospect – is likely to think in terms of high level features or changes: “Improve performance of adding a new user to the system”; “Tracks should be sorted by ignoring the word ‘the’”; “New blue-themed look Admin screens”.

It’s not just the descriptions – that would be easily resolved. But more difficult to overcome is the granularity. A single feature (e.g. “Allow a user’s account to be disabled”) might involve multiple code commits. Perhaps by a number of different developers or designers. So now your developer has a number of lower-level changes and descriptions which are all part of a single piece of work as far as management or customers are concerned. And while one of those more granular changes may be concerned complete by a single programmer, the project manager knows that it’s not until all the associated pieces of work are complete that the task is really complete,

So it’s become an issue of communicating the right information to the right audience. And I don’t think you can ignore either your developers nor your managers and customers.

You need both source code control and you need effective task-tracking.

This has been the case for as long as I can remember (from those heady days of Paradox and Digital CMS, through proprietary databases and CVS, to Bugzilla and svn.) But despite there clearly being a role for both systems, and despite the prevalence of such systems, integration of the two is another matter. Getting Bugzilla to talk to svn and vice versa is not trivial. And there is certainly no inherent capability in either product.

There are “workaround” solutions to this – for example, getting developers to commit code changes for a single task in one single commit operation. Or get developers to keep track of the revision numbers associated with their issues. But these are largely impractical (or force a suboptimum development process on the team) or are labour intensive and subject to human error.

There are tools which can facilitate these tasks – such as trac (of which I have almost no experience but hear many good things – but am not convinced it meets all of the requirements.) I’d welcome more feedback on trac and tools which might help tackle the problems I’ve outlined above.

But ultimately I think to solve the twin needs of task tracking with Bugzilla and source code control with svn, it is necessary to choose between implementing some glue between the two or accepting some increase overhead (and risk) in manually running both in parallel.