Mercurial: The Definitive Guide

Finding the Source of a Bug

While it’s all very well to be able to back out a changeset that introduced a bug, this requires that you know which changeset to back out. Mercurial provides an invaluable command, called hg bisect, that helps you to automate this process and accomplish it very efficiently.

The idea behind the hg bisect command is that a changeset has introduced some change of behavior that you can identify with a simple pass/fail test. You don’t know which piece of code introduced the change, but you know how to test for the presence of the bug. The hg bisect command uses your test to direct its search for the changeset that introduced the code that caused the bug.

Here are a few scenarios to help you understand how you might apply this command.

• The most recent version of your software has a bug that you remember wasn’t present a few weeks ago, but you don’t know when it was introduced. Here, your binary test checks for the presence of that bug.

• You fixed a bug in a rush, and now it’s time to close the entry in your team’s bug database. The bug database requires a changeset ID when you close an entry, but you don’t remember which changeset you fixed the bug in. Once again, your binary test checks for the presence of the bug.

• Your software works correctly, but runs 15% slower than the last time you measured it. You want to know which changeset introduced the performance regression. In this case, your binary test measures the performance of your software, to see whether it’s ...