Integrating Bug Trackers and Version Control

« previous entry | next entry »
May. 5th, 2008 | 01:03 pm

I'm interested in doing more than simply having a copy of the issues I'm working on when I'm offline. One of the attractions of things like Ditz and Bugs Everywhere is that they're integrated with the version control system used for source code. If you check out the code, you automatically have a copy of the current list of things that should be addressed. Your commits can reference issues and you at least know that they're in the repository somewhere. In Ditz, at least, you can attach issues to releases, which presumably correspond to a tag/branch, thereby providing linking in another direction.

If you don't think integrity is an issue, this probably seems like a silly exercise. Still, I've had projects switch issue trackers enough times to make it a consideration.

We can, and should, do better, though. Every modern VCS (SVN, git, Mercurial, etc.) provides identifiers for a state of a repository. Other than the pain of integration, it would be awesome to leverage these. We can say "bug identified at version X and 'fixed' with commits A, B, C". Even handier, you should be able to determine which revisions (and in what branches) the bug still affects. Once the bug is fixed, you should be able to look backwards as well as forwards and find versions that are also likely to be affected.

Again, in a perfect world of linear versions, this doesn't make sense. Branching, backporting, and other convolutions of history are fairly common, though. At one of my recent jobs this was a central task.

Ditz gets a clever point because you can say "I'm working on this bug right now." Using this information allows you to, with some inspection, determine what bugs are bound to what commits. However, I fear that this will be confused with the current shared-state concept of assigning bugs to people.

Shared properties are, without a doubt, useful tools. Other common ones include CC (notification) lists, target milestones/releases, and discussions (comments). I've noticed that these are either project management (assignment, targets) or communication (notifications, discussions). I think that it's a bad idea to bind these to version control tools (more precisely: putting them in the same repository as the code). Unlike bugs and features, they're not properties that the code has.

My conclusion bug tracking would greatly benefit integration-via-plugin for a version control system. The plugin would be able to annotate commits with issues and track what affects a given version of code. Tight coupling seems key to doing this well. The coupling with the shared-state, non-code system can be much looser; bridges between, say, Trac and git-with-bugs would be fine. Note that, for purposes of integrity, the description should be copied. This is not an error, because even if it changes in the issue tracker, the older (now committed) copy would reflect what you were working on at the time.

I might argue that the general issue trackers should push bugs into the version control system, but this is a task that seems to benefit from an air gap. For example, an earlier revision can be found for a regression.

Link | Leave a comment | Add to Memories | Tell a Friend

Comments {6}

Daniel Stutzbach

(no subject)

from: [info]agthorr
date: May. 5th, 2008 08:56 pm (UTC)
Link

Again, in a perfect world of linear versions, this doesn't make sense. Branching, backporting, and other convolutions of history are fairly common, though.

If regression testing is built-in to the VCS, it gets a lot easier to keep track of which versions have which bugs. The Mozilla folks pioneered this with their Tinderbox tool.

Unfortunately, I don't know of any tool like tinderbox that integrates easily with distributed version control systems like darcs and git. (I'm a darcs user, myself) If you find one, please post about it. :-)

Thanks for the pointer to ditz and bugs-everywhere, by the way. I've been using Trac, but it doesn't integrate all that well with darcs. ditz looks perfect for my needs.

Reply | Thread

Atrus

(no subject)

from: [info]nikolasco
date: May. 5th, 2008 09:44 pm (UTC)
Link

You still have the problem of newly-discovered bugs that weren't tested for in the older versions, or the regression cropped up while in a private branch/repo. You can use something like the bisect/trackdown command, but it seems like the process would benefit from more information (and explicit annotation seems like a happy thing).

Re: Tinderbox: check out Buildbot

Reply | Parent | Thread

Jeff Lindsay

(no subject)

from: [info]progrium
date: May. 6th, 2008 07:58 am (UTC)
Link

I'm glad more people are thinking about this and I'm glad you're sharing this because at some point we're going to try and solve distributed project infrastructure.

Reply | Thread

Evan Martin

(no subject)

from: [info]evan
date: May. 8th, 2008 04:37 am (UTC)
Link

Thanks for the link!

I agree with most of the points you make here, but it's also still not quite clear to me that it belongs in the source repo. I think most of the problems stem from the fact that history (in the sense of provenance/origin/parents) and time sometimes match but sometimes don't.

I have the distinct feeling someone is going to solve this problem in a compelling way and it'll be so obvious we'll all begin using it.

Reply | Thread

Atrus

(no subject)

from: [info]nikolasco
date: May. 8th, 2008 06:00 am (UTC)
Link

it's also still not quite clear to me that it belongs in the source repo
The more I think about this problem, the more I agree. From a modeling standpoint, having bugs looking like source files is icky.

Out of the distributed systems, git is the only one I can think of that keeps branches bundled together in the same repository. It's also the only one that rewrites history. Both are key to putting bug tracking in the source repo.

With separated branches, it's not at all clear how you'd "update bugginess." The operation is obviously distinct from pulling code itself.

Also, for tracking propagation, you'll likely want to mark stuff in the past. Even with git, this isn't feasible once changes have been shared.

It just generally reeks of "you put metadata in my data!" Having something that worked in tandem with the source repo would also have a big portability advantage... (besides, the thought of jiggling git internals seems very un-fun, and support for git seems necessary)

Reply | Parent | Thread

Evan Martin

(no subject)

from: [info]evan
date: May. 8th, 2008 01:47 pm (UTC)
Link

Paragraph-by-paragraph:
It doesn't bother me for bugs to be stored alongside source files. Ultimately they've got to go into some disk-based representation, so it may as well be a file per bug.

I think monotone, Mercurial, and fossil(?) also keep branches in the same repo.

Updating bugginess versus pulling code: either you're offline (in which case you can't do a network operation) or you're online (in which case you may as well push with every change -- it's just as expensive as an HTTP post). But you don't want to push the current branch (maybe it's a work in progress) which again points to not putting bugs in the current commit.

You can't really rewrite history, even in git, on a real project. And in practice I don't think people want to attach bugs to where they were introduced, they want to attach them to where they were discovered. By that I mean that when I discover a bug, I'm not going to go through old versions of the code trying to find the oldest version that exhibits the problem. With that in mind, I think of a bug as an annotation on a branch+version that persists in all subsequent versions (including merges). It's much more like the way branches work in monotone than in other systems.

Reply | Parent | Thread