monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] new bisect command


From: Derek Scherger
Subject: Re: [Monotone-devel] new bisect command
Date: Thu, 17 Dec 2009 21:49:16 -0700

On Tue, Dec 15, 2009 at 1:18 PM, Thomas Keller <address@hidden> wrote:
Am 01.12.09 06:49, schrieb Derek Scherger:
> On Tue, Nov 24, 2009 at 12:59 AM, Thomas Keller <address@hidden
> <mailto:address@hidden>> wrote:

At first sorry for answering this late. Too much attention withdrawn on
other things lately...

No problem, I've been distracted for the last little while as well.
 

> Agreed. I haven't made any changes here yet, but the describe_revision
> function should probably be updated to output localized dates. At the
> moment the only thing that localizes dates is the log command.

As this change can be main directly on nvm, it shouldn't affect your branch.

Yeah, I'm ignoring this for now.
 
Well, my blunt approach here would have been to use
database::get_common_ancestors() and look if the returned list is empty.
If yes, the revision should be part of another tree and thus not be
considered in the bisection, no?

Sounds plausible. Every time more revisions are marked as good/bad/skipped recompute the set of common ancestors of all the good/bad/skipped revisions and if that set becomes empty reject the new additions? I don't know if this is really all that important although it's probably a small change, I'm somewhat tempted to not worry about it for now.

If we ensure that the revisions are all in the same tree like above, we
could probably simply compare the revision heights, i.e. if we recorded
a bad revision with revision height X and another bad revision with
revision height > X should be recorded, than the latter should not be
considered because the bug seem to have been introduced in a revision
with height <= X, right? The same is true for good revisions, just that
we should not record any with a height smaller than the last good
revision we already have been recorded.

But actually I'm not sure if this is also the correct thing for
non-linear development lines, in which case we'd falsely exclude
good/bad revisions we actually need to find the bug. Unfortunately I'm
too brain dead at the moment to think about a graph which would reveal
such a misbehaviour.

I'm tempted to leave this for now too, so that I can finish updating the texi and merge.

Cheers,
Derek


reply via email to

[Prev in Thread] Current Thread [Next in Thread]