4

Usually, at the end of a hg bisect -c "my command" I get note saying I should run hg bisect --extend <ancestor_cset> to continue my bisection deeper.

I am using mercurial 2.1.2. Before mercurial 2.1, I the message was to use hg update instead of hg bisect --extend

It becomes really annoying went the culprit cset is like 10 levels deep so I have to manually do this command 10 times hg bisect --extend <ancestor_cset> && hg bisect -c "my command".

Is there a way to just automate the --extend part and carry one with bisection until the culprit cset is found?

Long Vu
  • 281
  • 1
  • 10
  • Can't you just run `hg bisect --extend -c "my command"` rather than the two commands you're currently doing? Looking at the code suggests that will work. – Paul S May 08 '12 at 13:51
  • Combining --extend with -c doesn't work. I got "abort: incompatible arguments". Besides, I was looking for a way to automate --extend each time it's required, not to combine --extend with -c. – Long Vu May 10 '12 at 14:27
  • Ah, that is being caught earlier on in the code. I missed that. I was expecting it to go into the normal bisect-check-bisect... loop, but use extend as necessary until it got to a changeset that wasn't a merge. Shame. – Paul S May 11 '12 at 09:01

1 Answers1

7

Bisect won't go outside the initial range of changesets. So if you initially set changeset 10 as good and changset 20 as bad, and after a few iterations cs 12 is found bad but is a merge with cs 5, bisect will stop. --extend is then used to expand the range outside the initial 10-20. If you want to search the entire range, set cs 0 as good and tip as bad and you should never need to use extend.

Consider the following history. Changeset 4 introduces a "bug".

@  12:8ae1fff407c8:bad6
|
o  11:27edd4ba0a78:bad5
|
o    10:312ba3d6eb29:bad4
|\
| o  9:68ae20ea0c02:good33
| |
| o  8:916e977fa594:good32
| |
| o  7:b9d00094223f:good31
| |
o |  6:a7cab1800465:bad3
| |
o |  5:a84e45045a29:bad2
| |
o |  4:d0a381a67072:bad1
| |
o |  3:54349a6276cc:good4
|/
o  2:4588e394e325:good3
|
o  1:de79725cb39a:good2
|
o  0:2641cc78ce7a:good1

Now if I mark changeset 7 as good and tip as bad, then 10 as found as the first bad changeset, but it is a merge and suggests extending the search to changeset 2 (the common ancestor):

C:\data>hg bisect -r
C:\data>hg bisect -g 7
C:\data>hg bisect -b tip
Testing changeset 9:68ae20ea0c02 (5 changesets remaining, ~2 tests)
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

C:\data>hg bisect -c check.bat
Changeset 9:68ae20ea0c02: good
Changeset 10:312ba3d6eb29: bad
The first bad revision is:
changeset:   10:312ba3d6eb29
parent:      9:68ae20ea0c02
parent:      6:a7cab1800465
summary:     bad4

Not all ancestors of this changeset have been checked.
Use bisect --extend to continue the bisection from
the common ancestor, 4588e394e325.

But if I set changeset 0 as good and tip as bad, it finds the right changeset without extend:

C:\data>hg bisect -g 0
C:\data>hg bisect -b tip
Testing changeset 6:a7cab1800465 (12 changesets remaining, ~3 tests)
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

C:\data>hg bisect -c check.bat
Changeset 6:a7cab1800465: bad
Changeset 3:54349a6276cc: good
Changeset 4:d0a381a67072: bad
The first bad revision is:
changeset:   4:d0a381a67072
summary:     bad1
Mark Tolonen
  • 166,664
  • 26
  • 169
  • 251
  • Bisecting with a range of 0 to tip is not scalable. Our repo has 130228 commits so far. Bisecting with this range will surely take many days ! However this gave me an idea: find the roots of the new "untested" csets and use that as bisect starting point. Probably something like hg log -r 'roots(.. bad_cset - .. good_cset)'. Will try this next time I need to use bisect again. – Long Vu May 11 '12 at 17:25
  • That's about 17 bisections. It's logarithmic. 2^17 = 128K. You could have 4 billion change sets and it would only take 32 bisections. – Mark Tolonen May 11 '12 at 22:09
  • Ah true ! You got me here :) Let me try to convince you again it's still not scalable: at rev 0 the broken file don't even exist yet so I can't give -c "make TheBadObjectFile.o". I could give -c "make" and do a full build at each bisection but then it will not be just a minute or 2 per bisection but an hour per bisection * 17, then we won't even know who broke the build by the end of the day. – Long Vu May 12 '12 at 01:40
  • 1
    Then only 256 changesets will take 8 hours. That your testing cycle takes an hour is unfortunate, but only 17 hours for 130228 changesets still is pretty scalable for such a long test cycle. – Mark Tolonen May 18 '12 at 16:23
  • Am I right that you can't expect this to work if the test has failed sometimes in the past? (Bisect might find some failing period other than the latest.) – Joshua Goldberg Nov 02 '12 at 20:43
  • There is an `hg bisect --skip` command to skip changesets that you can't tell are good or bad, like a changeset that won't build, but otherwise yes, you could find a different changeset if the test fails and passes at various times in the past. – Mark Tolonen Nov 03 '12 at 06:30