Re: hints for identifying a problem patch?

[Phil Edwards <phil at jaj dot com>]

On Thu, May 02, 2002 at 01:05:15PM -0700, Janis Johnson wrote:
> I suspect that my attempts to find out which patch caused a particular
> test to start failing are horribly inefficient.  Can people who do this
> sort of thing regularly please share some hints?  Once I understand a
> good way to do it I'll write up some directions to include in the web
> pages somewhere.  On the other hand, if such documentation already
> exists, it needs to be easier to locate.

I just wrote an email giving hints on how to do the binary searching trick
in CVS.  (Maybe you're investigating the same problem.)

=========================
> you perhaps give me some hints on checking out the sources corresponding 
> to a given time-date?

Normally, "cvs {checkout|update} -D datespec other_update_args" is what
I'd use to rewind an entire tree to 'datespec'.  Then "cvs update -A"
to reset the timestamps and bring the tree back to the present.

CVS is amazing when it comes to understanding the 'datespec'.  You can pass
almost any date/time format you can think of.  I have used arguments like

    -D yesterday
    -D 'last week'
    -D sunday
    -D '3 weeks ago'

etc.  You can specify clock times, timezones, "last fortnight", etc.


> Some general advice on the so-called binary-searches, would be also much 
> appreciated: of course I can imagine what does it mean from an 
> algorithmic point of view but I never really did one with CVS :-(

I've never needed to do one yet, fortunately, because the ChangeLogs and
"cvs log" and "cvs annotate" have so far always given enough hints for me
to get at least the right revision number.

The idea of course is to look for when a bug was introduced, i.e., one
present now but absent in the past.  For a completely general binary search
since a particular date, it would have to be something like

    boundary_date = that particular date
    newdate = halfway between boundary_date and now
 *  cvs update -D newdate
    bootstrap and test
    if the bug has disappeared, then
        newdate = halfway between newdate and now
    else
        newdate = halfway between boundary_date and newdate
    go to *

and repeat until you find the day on which the bug appeared.  From there,
it's a binary search on revision numbers instead of dates (assuming more
than one commit per day).

You could also do the search by revision number instead of date.  Usually
looking over "cvs log the_file_in_question" will give you an idea of which
is more appropriate (by date or by revision).


I don't believe anybody has tried to automate this.  Yet.  :-)

=========================


-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams