Re: Libata VIA woes continue. Worked around - *wrong*

[Jeff Garzik <jgarzik@pobox.com>]

Brad Campbell wrote:
> Jeff Garzik wrote:
> 
>> * look at the changes from 2.6.5 -> 2.6.6 and see which change breaks 
>> things.  You can get a list of each change like this:
>>
>>     bk changes -rv2.6.5..v2.6.6
>>
>> then you can revert each patch in order, or bsearch.  Here's an 
>> example of reverting each libata patch in order:
>>
>> bk clone http://linux.bkbits.net/linux-2.5 vanilla-2.6
>> bk clone -ql -rv2.6.6 vanilla-2.6 brad-test-2.6.6
>> cd brad-test-2.6.6
>> bk -r co -Sq
>> bk changes -rv2.6.5.. > /tmp/changes-list.txt
>> less /tmp/changes-list.txt    # scan for a libata-related change
>> bk cset -x1.1587.39.2        # applies reverse of cset 1.1587.39.2
>> make                # create test
>>                 # ... test fails
>> bk cset -x1.1587.39.1        # applies reverse of cset 1.1587.39.1
>>                 # _on top of_ previous reverted patch
>> -
> 
> 
> Ooooohh. I have been looking for a "Dummies guide to regression testing 
> with BK" and not been able to find one. I have cc'd this to linux-kernel 
> purely for the purpose of more googleable archives for future reference 
> for BK newbies like me.
> 
> Cheers Jeff!
> 
> I'll start hammering on this tonight.

Groovy :)

Since BK changesets are ordered as a progression, you can also do a 
bsearch by clone trees to specific changesets, such as

bk changes -rv2.6.6..2.6.7 > /tmp/changes.txt
# view changes.txt, pick out cset 1.1587.39.1 as your "top of tree"
bk clone -r1.1587.39.1 vanilla-2.6 brad-test-2.6.6-bk
# compile and test the kernel in brad-test-2.6.6-bk

Since we're CC'ing lkml to add to the collective wisdom, maybe Larry or 
Linus have something to add, WRT tips on efficiently narrowing down a 
regression in the kernel, using BK.  I am _definitely_ not a BK wizard 
in this specific area.

	Jeff