1. TortoiseHg
  2. TortoiseHg
  3. thg
  4. Issues
Issue #305 open

bisect usability trouble

Benoît Allard
created an issue

I liked the way bisect was integrated in the repository explorer in the old gtk version.

I also like the way it is now integrated it is really easy to use, actually, I could live with both, anyway, I've found a trouble with the new (2.0) way of using bisect:

Under some circumstances, the GUI thinks it is finished, even if mercurial reports that the investigations could continue. See the following message:

{{{ [command completed successfully Thu Mar 10 15:54:34 2011] % hg bisect --repository C:\InstallShield Projects\3.0\product-installer --bad . The first bad revision is: changeset: 461:71cf613ab3ac branch: x64 parent: 456:72d4e517c84e parent: 460:c65ed8fcd983 user: Benoit benoit@aeteurope.nl date: Thu Mar 10 14:15:42 2011 +0100 summary: merged

Not all ancestors of this changeset have been checked. To check the other ancestors, start from the common ancestor, 9e2f3c85e9df. [command completed successfully Thu Mar 10 15:54:39 2011] }}}

This is to reproduce with such a DAG:

{{{ o 9: bad | o 8: bad |\ | o 7: good | | o | 6 |\| | o 5 | | }}}

With as parameters for the dialog good: 7, bad: 9, 8 is proposed, diagnosed as bad, and here come the message and the wrong assumption from thg that the bisect is done. Mercurial, hints at testing 5.

I think thg should update to 5 and ask the result of the investigation.

Comments (6)

  1. Benoît Allard reporter

    Do you mean the .hg/bisect.state file ?

    I don't know how this file could hints you at any state ... it is just a list of good and bad revisions ...

    Anyway, here is its content after the message above:

    bad 71683ea8b6feee1201984d27c32d2fc734e4e9c5
    bad 71cf613ab3ac32ba86ee8fd7a2ce2686cd527bae
    good c65ed8fcd9832630ad9de6354062b2359c6a2cd9

    Where: 7168 is known as 9 in my example, 71c6 as 8 and c65e as 7

    Then I guess the most error-prone method would be to replicate the content of the print_result function. I don't know what's your politic about reuse of mercurial code though.

    Another solution would be to restore the possibility to give the result of a bisect investigation with the right click.

    Or maybe, it should be considered as a mercurial issue when mercurial considers the bisection to be done when it is actually not. (Or only between the markers initially given) I'll open a mercurial issue for that.

  2. Steve Borho

    I haven't had a chance to look closely at it. I presume the tool will have to add the flag to the bisect command line when appropriate. Not a big deal, I can include that when I refactor bisect into a QWizard style dialog.

  3. Log in to comment