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

Matt Mackall mpm at selenic.com
Fri Sep 16 16:50:41 CDT 2011


On Fri, 2011-09-16 at 23:40 +0200, Yann E. MORIN wrote:
> Matt, All,
> 
> On Friday 16 September 2011 01:52:23 Matt Mackall wrote:
> > On Fri, 2011-09-16 at 01:28 +0200, Yann E. MORIN wrote:
> > > - 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)'
> > 
> > This one's actually trickier.
> > 
> > Depending on which edge direction we've inferred,
> 
> It never occured to me that a regression could be the other way around.
> But it makes sense, I agree. A direct bisection (bad<good) is to find the
> cause of a regression; a reverse bisection (good<bad) is to find where a
> bug disapeared. And after all, good/bad are only meaningfull for us mere
> humans, and could be use either way... ;-)
> 
> > we might want to either have:
> > 
> > bisected(skip) and ancestors(bisected(good)) and descendants(bisected(bad))
> > 
> > or
> > 
> > bisected(skip) and ancestors(bisected(bad)) and descendants(bisected(good))
> 
> OK, you want only skipped csets that are still in the bisection range (eg.
> skipped csets that are out-side the bisection scope get removed).
> 
> OK, got it.

Bah, that should all be 'or' rather than 'and'.

> > > - 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)'
> > 
> > s/pruned/skip/
> 
> good::bad will also return the good and bad csets, but those are not
> untested: they are good (or bad). 'untested' is for remaining csets,
> which we do not know whether they are good/bad?
> 
> So we should also exclude good and bad sets from the result, no?

Correct.

> > This also has the directionality issue.
> 
> OK.
> 
> > > - 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)'
> > 
> > Note that we can simply define any of these sets in terms of the other
> > two:
> > 
> > ignored = !pruned and !untested
> 
> With such a definition, 'ignored' will return *all* csets of the repo,
> except the pruned or untested ones. 'ignored' conveys a stronger meaning,
> that is "csets that can't participate to the bisection, but might have
> an impact on the outcome"; such as you perfectly explained with a merge
> in the middle of good::bad
> 
> But if am wrong on all the above, just correct me (once more!) ;-)

No, you're right. The 'interesting' ignored set is any ancestor of the
untested set that is not in pruned or untested.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list