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
