views:

44

answers:

2

After a bug has been located and fixed, we would like to trace the bug back to the change that originally caused it. That way, our team can look at it and learn how to avoid that type of bug in future changes.

Obviously, if automated tests catch the bug, then it was probably a recent change. But that doesn't work in the case where the bug made it into the wild before it was caught. Are there any tools that can go through the source control history and make an educated guess about which changeset caused a certain bug?

+5  A: 

svn blame is great for this.

If you can identify one or more lines of code that caused a bug, you can run svn blame on the file(s) and see in which revision they were introduced and by which user.

Mike
Of course, this also exists for other VCS systems, including Mercurial (hg annotate, aliased to hg blame) and git (git blame). See http://www.selenic.com/mercurial/hg.1.html#annotate and http://ftp.sunet.se/pub/Linux/kernel.org/software/scm/git/docs/git-blame.html
Matthew Flaschen
+1, it's an equally right answer to the question.
Johannes Rudolph
I've used blame before, it's pretty useful. But I was hoping to find something that required less manual comparison work to find the actual bug.
Josh Yeager
+3  A: 

Apart from using blame which is best used when you know the exact cause of the bug, most modern DVCS feature some kind of bisect mechanism. This is best used in case you can reproduce the error in some way and are sure it worked some time ago, however you don't know the exact cause. For example in Mercurial it works like this:

Its behaviour is fairly simple: it takes a first revision known to be correct (i.e. without the bug) and a last revision known to be bad (i.e. with the bug). The bisect extension ouputs a revision halfway between the good and the bad ones and lets you test it. If this revision is a good one, you mark it as good with hg bisect good, otherwise you mark it as bad with hg bisect bad. In both cases, bisect outputs a new revision to test, halfway between the good and the bad ones. You repeat until only one revision is left: the culprit.

The search is therefore always in O(log(n)) time max and can be very well automated with bash/shell scripts. As with blame, git supports that too, don't know about svn.

Johannes Rudolph
Linus explains why use "git bisect": http://kerneltrap.org/node/11753
Yacoder
That's exactly what I was looking for. Thanks!
Josh Yeager