[darcs-users] [patch106] resolve issue1208: trackdown --bisect (complete branch...

[mf-hcafe-15c311f0c at etc-network.de]

On Wed, Mar 31, 2010 at 02:49:30PM -0400, Max Battcher wrote:
> To: Ganesh Sittampalam <bugs at darcs.net>, darcs-users at darcs.net,
> 	dixiecko at gmail.com, ganesh at earth.li,
> 	mf-hcafe-15c311f0c at etc-network.de
> From: Max Battcher <me at worldmaker.net>
> Date: Wed, 31 Mar 2010 14:49:30 -0400
> Subject: Re: [darcs-users] [patch106] resolve issue1208: trackdown --bisect
> 	(complete branch...
> 
> Eric Kow wrote:
>> 1. What problem does the proposed feature solve?
>>
>>    EYK: Efficiently identifying a set of patches in the repository which
>>    cause a test to pass (or was it fail?).  We currently have plain old
>>    darcs trackdown, but it only works one patch a time, which makes it
>>    rather painful.  Trackdown --bisect would presumably be a lot faster.
> [snip]
>>    Also, could we even take a step further and pro-actively enhance the
>>    user interface by renaming darcs trackdown to darcs test.  The idea
>>    then is that darcs test by itself just runs the test, and
>>    darcs test --trackdown and darcs test --bisect do trackdown-ish tasks?
>
> The obvious question here, particularly in the pro-active case: if  
> --bisect is preferable in most/all cases (it should be faster in most  
> cases, right?), perhaps --bisect should be the default "trackdown" and  
> the current one renamed/deprecated?
> 
> That is, what are the use cases where one would prefer existing  
> trackdown over trackdown --bisect?

when i was still up to date what's going on with this patch, it wasn't
possible to restrict the range of patches to search.  this can be a
problem if the test script acts non-continously over the complete
repository (i.e. used to work some time, then not work, then work
again...).  in that case you'd want to either work the patch set
linearly backwards to find the most recent point of change, or
restrict the search space to a fraction of the repository on which the
script acts coninously, or both.

i'm not sure if the current --bisect command allows that?

also the linear search is easier to understand.

thanks rado for not letting this feature die!  (-:


cheers,
matthias