[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