On Wed, 27 Nov 2019, Eric S. Raymond wrote: > Joseph Myers <jos...@codesourcery.com>: > > > I'm more worried about missing files. I saw a bunch of those on my > > > last test. This could be spurious - the elaborate set of branch > > > mappings you specified confuses my validation test, because there is > > > no longer a 1-1 corresponsence between Subversion and git branches. > > > > I'm hoping any such missing file problems come from bugs in the old SVN > > dump reader with complicated commits mixing copies / deletions / > > replacements with copies from other locations and that your rewrite will > > fix the semantics in such cases. > > Also possible. > > The old code was a hairball. The new code is a bunch of relatively simple > sequential passes - 10 so far, final version likely to have 12 or 13 - with > well-defined preconditions and exit contracts. If nothing else this is > going to make troubleshooting any remaining defects much easier.
I did a comparison of git and SVN checkouts to look at missing file problems. I've now filed reposurgeon issues 171 and 172 for the problems I noted. Issue 171 relates to handling of trunk deletion / recreation. Issue 172 relates to the first point where missing file problems appear (unless some appeared and then disappeared in the history before then). As it's at a very early point in the GCC history (r14877), hopefully it shouldn't be too hard to track down if your rewrite doesn't fix it, since it shouldn't require loading much of the history to reproduce. (Roughly, it's at the start of EGCS, i.e. around the point where we spliced together the gcc2 and EGCS CVS histories when converting from CVS to SVN. So some bits of the history around then may well look weird, but I don't see anything particularly odd about that particular SVN commit.) -- Joseph S. Myers jos...@codesourcery.com