How important is version control integration with your bug tracking software

Question

Currently we use FogBugz for tracking issues and found it to be ok. I'm looking for something else that can allow end users the ability to track their cases along with us. And something that actually works well with email. I've found a few alternatives that support those features but they don't integrate with version control. We've got all the SVN hooks in fog bugz and we use them - but I haven't really found them all that useful. Has anyone found a really good reason to need version control integration with the bug trackers?

Answer 1

Clearly, this kind of integration is not something that is essential to the operation of the software. With a bit of discipline every check-in can be accompanied with a bug number manually, and every bug resolution can manually have a version control tag added to it.

All else being equal however, I personally will always prefer automation over 'discipline of the users', because the latter will always sooner or later let you down from time to time. Not because the users are malicious or incompetent, but simply because people cannot be 100% alert all of the time.

Answer 2

It is a question about your code size, and how many bugs you need to track.

And it is also really useful for non coders in the organisation i.e. managers and customer support. They can find answers to questions like "When and where was this bug fixed"...

Answer 3

I think it's helpful to distinguish between bugs found internal to the development organization, e.g. from peer code review, versus bugs found by a test group that is external to the development organization.

The (small) benefit to coordinating version control with bugs found by an external test group would be for historical reference.

The larger benefit is in coordinating bugs found via peer code review with version control -- by doing so you can certify that all code is peer review bug free before releasing it to external test groups; a common requirement.

FYI, Code Collaborator from SmartBear, Inc. handles this nicely.

Answer 4

I find the integration of SVN with TRAC very helpful. Through SVN hooks, commits to the repository with a ticket number insert a comment on the ticket with a link to a nice visual HTML representation of the revision number, showing inserts, deletes, and diffs.

As a supervisor over a small team of programmers, I find this as a helpful tool for me to do code reviews, so I can verify that the commit truly addresses the associated issue. I wouldn't exactly call this integration essential, but it was a nice free extra on my issue tracker that I've grown to love.

Answer 5

It is absolutely critical for us.

Here is a typical commit log for one of our projects (sample):

Make sure filedes is cleared in child list prior to reallocating

When p->child-filedes is > 0, the child list is active and can not
be collected.

[ Impact: Closes bug 123457 ]

Note the [ Impact: ] line, which could also be "Relates-To", "Caused" or any number of other things.

This lets us use simple greps and automated scripts allowing the person committing to automatically close, or even re-open a bug.

Though we typically use Git and Mercurial, these sort of hooks would work on (almost) any VCS, especially proprietary ones that do not feature some modular plug-in that you need.

If you think of your bug system as just another part of your VCS, its really easy to see how they depend upon each-other.

Other stuff, such as fetching patches submitted with bugs is possible, too.

Answer 6

I have found version control integration to be extremely helpful in maintaining and managing multiple versions (stable, development trunk, etc.) of a project.

Using the version control integration and a bit of discipline from coders to reference bug tickets in commits (or some pre-commit hooks to forcibly require ticket references) has allowed us to quickly and easily generate lists of changesets that are required to fix any given bug. This is instrumental when merging the fixes into various stable branches of the code.

It's not a necessity, but it certainly makes life easier for release management.

I've used SVN + Trac and Atlassian's Jira product with Fisheye SVN plugin and have found both tools to be very good. Trac seems to be a bit simpler, but very easy to use. Jira, in my opinion, had a nicer look and feel and quite a few more bells and whistles, but was almost too much at times.