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: Thomas Keller
Subject: Re: [Monotone-devel] new bisect command
Date: Fri, 18 Dec 2009 10:31:34 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9.1.5) Gecko/20091130 SUSE/3.0.0-66.3 Lightning/1.0b1pre Thunderbird/3.0

Am 18.12.2009 05:49, schrieb Derek Scherger:
>     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.

Actually you'd only have to check one revision from which you know that
it belongs to the same tree like the other already recorded revisions
against each newly added good/bad/skipped. But sure, its not a big
thing, lets see if and how people will start using this new feature at
first.

>     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.

Ok, I'm looking forward to your merge to nvm then.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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