On Thu, 5 Dec 2019, Eric S. Raymond wrote: > I was much more worried about the conversion before we figured out > that most of the remaining content mismatches seem to radiate out from > something weird that happened at r14877. That's early enough that a > leading-segment load including it doesn't take forever. Which means > it's practical to do detailed forensics on the defect even if you don't > have handy an EC12 instance with ridiculo-humongous amonts of RAM.
I just tried a leading-segment load up to r14877, but it didn't reproduce the problems I see with r14877 in a full repository conversion - it seems the combination with something later in the history may be necessary to reproduce the issue. (With trunk-deletion-and-recreation being an obvious candidate, since *some* content problems definitely first appear at such commits.) If it's necessary to bisect to find what leading segment produces that problem (if it still appears with the new SVN dump reader), obviously things can be speeded up for the bisection by omitting slow things such as the deletion of emptycommit tags (a minimal gcc.lift makes sense for such a bisection anyway). -- Joseph S. Myers jos...@codesourcery.com
