[PATCH 1 of 1] bisect: print current state of the bisection

Yann E. MORIN yann.morin.1998 at anciens.enib.fr
Thu Sep 15 18:28:46 CDT 2011


All,

On Thursday 15 September 2011 18:56:05 Yann E. MORIN wrote:
> # HG changeset patch
> # User "Yann E. MORIN" <yann.morin.1998 at anciens.enib.fr>
> # Date 1316105758 -7200
> # Node ID 1538635da29a21230eff455150c1a2b166f2375a
> # Parent  edf7ae547b0e475936831fb8459c850d13b2d310
> bisect: print current state of the bisection

Forget about this. We've discussed this with mpm on IRC, and here's the
summary of the discussion (at least what I have understood):

Enhance revset's bisect() keyword to accept three new definitions:

- pruned:
    all changesets that we know already participated in the bisection
    so far, basically, all good, bad and skipped changsets; so the set
    is:
      'bisected(good) | bisected(bad) | bisected(skip)'

- untested:
    all changsets that are not yet tested, and that are potential
    candidates for later tests; basically, it means that:
      - all changesets already tested are excluded
      - all descendant of good changesets that are ancestors of
        bad changesets, are included
    so the set looks like:
      'bisected(good)::bisected(bad) & ! bisected(pruned)'

- ignored:
    all changesets that can't participate in the bisection because
    of DAG topology. For example, a branch merged between the good
    set and the bad set, but whose branch point is before the good
    set, will not participate in the bisection, although the issue
    may originate from that branch [*]; what this means is:
      - all changesets already tested are excluded
      - all ancestors of bad changesets that are not ancestors of
        good changesets, are included
    so the set looks like:
      '( ::bisected(bad) - ::bisected(good) ) & ! bisected(pruned)'

[*] if so, then bisect will find the merged changeset as being the
    culprit, and suggest to extend the range

Then simply use the log command to print the corresponding changesets.
This has the nice advantage of profitting from all of the log features,
such as graphlog (if enabled), and can also be combined with other
revset keywords to refine the sets.

For example, if we know that the issue is in a specific file, we could
use a set like:
    'bisected(untested) & file(file/with/issue)'

If we know the issue was added the past two weeks, and has been present
for the last 5 days, the set could be:
    'bisected(untested) & date(-14 to -5)'

And so on...

Many thanks to mpm for taking the time to get me on the correct route! :-)

So, I'll get back to the drawing board, and soon after to the keyboard.
But probably that will wait tomorrow GMT+2...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'


More information about the Mercurial-devel mailing list