If a particular string is known, an error message for example, bk grep can help find the file and revision of the file that contains the particular string (and hopefully, the bug). The default output is annotated with file name and revision number. If you have a general idea in which directory to check, use:

bk grep string

if not, it is possible to do the search on all files in a repository by doing:

bk -r grep string

If the file has already been found (this can sometimes be accomplished by an assertion or core file) run revtool on the file.

bk revtool file

Using revtool on the file, information about what was introduced in various revisions of the file can be found. When the revision that caused the bug is found, click on the View Changesets button, to see all the files associated with the one that caused the bug. This will give a picture of what happened at a particular point in time to help illuminate the problem.

When All Else Fails - Binary Search

BitKeeper employs the concept of binary search when trying to track down elusive bugs. A range of time of when the bug was introduced is needed. This can be sometime between the first changeset and the last changeset, or it can be sometime between the last known good version and the first known bad version. The range can be anything as long as the lower bound does not have the bug and the upper bound does have the bug. The lower bound is the earlier cset (without the bug) and the upper bound is the later cset (with the bug).

Choose the changeset that occurs in the middle of the upper and lower bound. Clone the repository as of that changeset to a new repository and build the product.

bk clone -rmiddle_cset repository /tmp/repository make product