On Wed, 11 Dec 2019, Richard Earnshaw (lists) wrote: > On 11/12/2019 15:19, Jonathan Wakely wrote: > > On Wed, 11 Dec 2019 at 15:03, Richard Earnshaw (lists) wrote: > >> I wouldn't bother with that. There are known defects in the version of > >> reposurgeon that I used to produce that which have since been fixed. It > >> was *never* the point of that upload to ask for correctness checks on > >> the conversion (I said so at the time). Instead it was intended to > >> demonstrate the improvements to the commit summaries that I think we can > >> make. > > > > My concern is that there is no conversion done using reposurgeon that > > *can* be used to do correctness checks. > > > > I have concerns too, but I'm in contact with the reposurgeon guys and > progress *is* being made.
Concretely: when I did a comparison of the tip of trunk against master from a reposurgeon conversion on 29 November, there were 1421 differences (files or directories only present in one of SVN or git or with different contents). As of today with the SVN dump reader rewrite, this is down to just two differences (plus two empty directories present in SVN as git doesn't represent empty directories), and we understand exactly where the problem arises with a trunk deletion and recreation and what's odd about that particular trunk deletion and recreation. All the deleted tags and branches are now placed neatly in refs/deleted/; we no longer have any problems with deleted tags or branches wrongly appearing in the main tag and branch namespaces; all the mess with deleted branches appearing in the reposurgeon-generated "root" branch has gone, everything there now appears to relate to commits that genuinely and correctly do not go in any branch or tag (changes to the hooks directory, branches wrongly created at top level, etc.). Almost all the branches that previously weren't created in git by reposurgeon because they were not changed in SVN after branch creation are now properly present in the conversion to git. -- Joseph S. Myers jos...@codesourcery.com