[issue1864] bisect not aware of tree structure

[Mads Kiilerich]

New submission from Mads Kiilerich <mads at kiilerich.com>:

While trying to understand issue1860 I got this on crew:

[mk at localhost hg2]$ echo -e '#!/bin/bash\nexec grep ^_hg_bookmarks
contrib/bash_completion' > check.sh
[mk at localhost hg2]$ chmod +x check.sh 
[mk at localhost hg2]$ hg bisect -r
[mk at localhost hg2]$ hg up -Cr 33033af09308
71 files updated, 0 files merged, 0 files removed, 0 files unresolved
[mk at localhost hg2]$ hg bisect -c ./check.sh 
Changeset 9511:33033af09308: bad
abort: cannot bisect (no known good revisions)
[mk at localhost hg2]$ hg up -r 552c5a5a3502
73 files updated, 0 files merged, 0 files removed, 0 files unresolved
[mk at localhost hg2]$ hg bisect -c ./check.sh 
_hg_bookmarks()
Changeset 9459:552c5a5a3502: good
Changeset 9484:c96d73dd956d: bad
Changeset 9471:a15813fae0a8: bad
Changeset 9465:1214c64c592b: bad
_hg_bookmarks()
Changeset 9461:1f54b1b7122f: good
Changeset 9462:bd017f359c08: bad
Changeset 9457:ffeaf5ba25d8: bad
The first bad revision is:
changeset:   9457:ffeaf5ba25d8
user:        Steve Borho <steve at borho.org>
date:        Thu Sep 17 17:39:43 2009 -0500
summary:     demandimport: blacklist gtk

Bisect has been told that 9511 is bad and 9459 is good, but anyway it finds
9457 which is outside the range. The right answer would have been 9463. It
has been tricked by 9462 not being an ancestor of 9459.

It would be nice if bisect not just could handle linear development but also
subgraphs of more complex graphs.

As a workaround bisect could verify that it really ends up with good/bad
revisions which are parent/child of each other and bail out if not.

----------
messages: 10738
nosy: kiilerix
priority: bug
status: unread
title: bisect not aware of tree structure

____________________________________________________
Mercurial issue tracker <bugs at mercurial.selenic.com>
<http://mercurial.selenic.com/bts/issue1864>
____________________________________________________