Section 7.4. Integrating with SCM Tools


7.4. Integrating with SCM Tools

A common question when working with a particular bug is which files were affected by fixing the bug. The answer can tell you which branches the fix was applied to, suggest areas for regression testing, and even guide developers who are fixing similar bugs in the future. Without any integration with the SCM tool, the usual way to find out this information is by looking at which files changed around the time when the bug was fixed. This method is obviously prone to error and is also rather tedious in practice.

There are usually other changes to source code that are not related to bugs; for example, a spelling mistake in a comment doesn't usually need to be reported as a bug before it can be fixed. One common way to integrate the SCM tool and the bug tracking tool is to mark a particular set of changes that are being committed as related to a particular bug. This may done by using some special string of text in a commit message such as For bug 12345, carefully designed to be detected by the SCM tool, which then uses the bug tracking tool's API to add more information to the indicated bug or bugs. The information that's added to the bug depends on the SCM tool, but the names and versions of the affected files, along with the differences between the files or the changeset identifier, are commonly used. The special text in the commit message can also be used to cause the SCM tool to change the state of a bug.

This approach works reasonably well most of the time. It fails when developers forget to add the special text to the commit message or mistype some keyword in the special text. The ability to go back and mark a set of changes as associated with a bug after they have been committed is a good idea. Another problem is if the bug tracking system is unavailable when the changes are being committed. In this case, the changes can either be discarded, which means that the information in the bug tracking system is imperfect, or saved for applying later.

An alternate approach is for the bug tracking system to regularly extract the commit messages and their associated data from the SCM tool, and to use this information to regenerate the SCM-related information in each affected bug. This is the approach taken by JIRA, and while it is somewhat less scalable than adding the information at commit time, it does have the advantages of being more robust and making it easier to correct mistakes.

Many bug tracking systems provide some support for integration with numerous SCM tools (for example, CVS, Perforce, and ClearCase). For detailed information about how CVS and Bugzilla can be integrated, see http://www.einval.com/~steve/software/cvs-bugzilla and http://kered.org/article-2004.04.09-cvs_bugzilla_integration.html.



Practical Development Environments
Practical Development Environments
ISBN: 0596007965
EAN: 2147483647
Year: 2004
Pages: 150

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net