[PATCH 1 of 4] hbisect: add two private revset descriptions

Yann E. MORIN yann.morin.1998 at anciens.enib.fr
Thu Sep 22 15:31:17 CDT 2011


Matt, All,

On Thursday 22 September 2011 21:41:38 Matt Mackall wrote:
> On Thu, 2011-09-22 at 02:10 +0200, Yann E. MORIN wrote:
> > # HG changeset patch
> > # User "Yann E. MORIN" <yann.morin.1998 at anciens.enib.fr>
> > # Date 1316639690 -7200
> > # Node ID 85607e1e24e03e75410739cfee8465c3520ef0cd
> > # Parent  510184e5a09eb09be23b55bc1191c6ca77af05d5
> > hbisect: add two private revset descriptions
[--SNIP--]
> > -        pg = 'bisect(good)::bisect(good)'   # Pruned goods
> > -        pb = 'bisect(bad)::bisect(bad)'     # Pruned bads
> > -        ps = 'bisect(skip)'                 # Pruned skipped
> > -        pruned = '( (%s) | (%s) | (%s) )' % (pg, pb, ps)
> > +        goods = 'bisect(good)::bisect(good)'   # Pruned good csets
> 
> I don't understand these revsets.
> 
> If I have a graph that looks like:
> 
> a-b-c-d-e-f-g-h-i
>    \ \   / /
>     j-k-l-m
>     
> If my 'tested good' csets are [c k] and my 'tested bad' csets are [g],
> then my 'assumed good' csets are '::(c or k)' = [a b c j k]. In other
> words, everything to the left of c and k.
> 
> But it is not a given that goods come before bads! If we figure out it's
> backwards, we flip the logic entirely: 
> 
>  http://www.selenic.com/hg/file/510184e5a09e/mercurial/hbisect.py
>  (lines 59 and 62)
> 
> If our 'bad' csets are [a], then our whole picture flips and now our
> known-good csets are [c d e f g h i k l m]. In other words, everything
> to the right of c and k.
> 
> So it is impossible to calculate the good set without reference to the
> bad set! Second, both the assumed good and assumed bad sets are
> open-ended: they include everything in the graph to either the left or
> right. So the revset should be something like 'x::' or '::x', not
> 'x::y'.

I think we should restrict the status reporting to those csets that did
actually took part to the bisection. That is, only cset that are either
in the range, or ignored, should have a status. Here's why:

given that DAG:

    a-b-c-d-e-f

and the situation where:
 - a had a bug
 - c fixed it
 - f has the bug again

So now we are bisecting with:
 - c is marked good (it has the fix)
 - f is marked bad (it has the bug again)

So, we are actually bisecting (c::f), and marking a and b as good is just
plain wrong. We should restrain ourselves to the bisection *range*, because
that's all we know *for sure*.

This has the *side effect* that we do not care about the bads vs. goods
ordering; and we take advantage of this side effect.

Now, that brings another issue. Currently, the 'log --style bisect' will
always print the 'bisect:' entry, even if the cset is not in the range.
This is an annoyance; that line should *not* be printed if the cset is not
in the range. Like the 'tag:' line is not printed if the cset has no tag.

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