That light at the end of the tunnel?

[Jeff Law]

On 07/23/2018 08:53 AM, Joseph Myers wrote:
> On Mon, 23 Jul 2018, Richard Earnshaw (lists) wrote:
> 
>> So traditional git bisect is inherently serial, but we can be more
>> creative here, surely.  A single run halves the search space each time.
>> But three machines working together can split it into 4 each run, 7
>> machines into 8, etc.  You don't even need a precise 2^N - 1 to get a
>> speedup.
> 
> Exactly.  Given an appropriate recipe for testing whether the conversion 
> of history up to a given revision is OK or not, I can run tests in 
> parallel for nine different revisions on nine different machines (each 
> with 128 GB memory) at the same time as easily as running one such test.  
> (And the conversions for shorter initial segments of history should be 
> faster, so if the bug turns out to relate to conversion of cvs2svn scar 
> tissue, you don't even need to wait for the conversions of longer portions 
> of history to complete before you've narrowed down where the bug is and 
> can start another such bisection.)
> 
> I think parallelising the bisection process is a better approach than 
> trying to convert only a subset of branches (which I don't think would 
> help with the present problem - though we can always consider killing 
> selected branches with too many mid-branch deletealls, if appropriate) or 
> waiting for a move to Go.
Hell, I'd live with doing a "reasonable effort" for the vast majority of
our branches.  Other than the trunk, active release branches and a few
active development branches I don't think we really care about 'em.

jeff