How-to_Advanced_HGDissect

Back-to:World:How-to:Advanced

How to use Mercurial bisect

This is mainly addressed at folks who do run server just for development, and those who are not afraid of spending some time to locate bugs. Mercurial VCS provides us with excellent tool for locating regressions in code, its called bisect - and works exactly the way it sounds, it gets into revisions and tests them. All you have to do is answer mercurial wether revision is good (doesnt have bug youre looking for) or bad (has the bug). Let's look at example session with hg bisect i prepared, its linux OS but works exactly the same on windows. We're searching for a bug across 234 revisions:

[~/trinitycore] hg bisect -r

First, im reseting all previous bisect information, just to be safe.

[~/trinitycore] hg tip
changeset:   1465:6a307f5252b5
branch:      trunk
tag:         tip
user:        Anubisss
date:        Sun May 03 13:47:52 2009 +0200
summary:     *Add a missing script.

[~/trinitycore] hg bisect -b 1465

Now, first magic command. hg bisect -b <rev> marks bad revision - ie. revision with bug. You dont have to provide exact revision number, i usually use newest revision as reference.

[~/trinitycore] hg bisect -g 1234
Testing changeset 1349:dfaf9e90ef1c (231 changesets remaining, ~7 tests)
213 files updated, 0 files merged, 14 files removed, 0 files unresolved

-g marks revision you remember didnt have bug in it. It doesnt have to be precise, you just need to be sure revision was bug-free. Immediately mercurial will tell us how much revision our test span, and how many tests it will require to find the problematic revision. In this case it is 230 revisions, and 7 tests. Now all we do is test, and using hg bisect -g or hg bisect -b mark wether or not revision has the bug. Example paste:

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -b
Testing changeset 1291:fb334cd0178e (115 changesets remaining, ~6 tests)
112 files updated, 0 files merged, 10 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -b
Testing changeset 1262:4c034879ce77 (57 changesets remaining, ~5 tests)
305 files updated, 0 files merged, 1 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -g
Testing changeset 1276:a8cce604021c (29 changesets remaining, ~4 tests)
288 files updated, 0 files merged, 1 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -b
Testing changeset 1269:52bfc1120c83 (14 changesets remaining, ~3 tests)
279 files updated, 0 files merged, 0 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -g
Testing changeset 1272:6fc334b7ae87 (7 changesets remaining, ~2 tests)
275 files updated, 0 files merged, 0 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -g
Testing changeset 1274:3ae63686c2ee (4 changesets remaining, ~2 tests)
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -g
Testing changeset 1275:06ca2a2af74c (2 changesets remaining, ~1 tests)
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

raczman nie, 3 maj 2009, 14:16:00 CEST
[~/trinitycore] hg bisect -g
The first bad revision is:
changeset:   1276:a8cce604021c
branch:      trunk
user:        megamage
date:        Thu Apr 02 20:27:10 2009 -0600
summary:     *Fix some visibility bug.

Please note, that still you have to compile, and test the bug Mercurial only provides us with fast way of testing big revision spans.
At the end mercurial will tell us what changeset the bug was introduced in, which, as you can guess tremendously helps us fixing bugs We can safely reset bisect information after finishing work with:

[~/trinitycore] hg bisect -r

Again, reference:

hg bisect -g marks a good revision
hg bisect -b marks a bad revision
hg bisect -s skips revision, if you are sure you dont have to test that one, or can't otherwise determine if revision is good or not.

I think that's all, remember: only user input and testing helps us to locate bugs.
This method is best for all those things that broke but were working several revs ago. If you have more questions about bisecting, leave it here

– original by Raczman from TrinityCore forum.