First, my apologies for not responding five days ago. Joseph's mail issued as I was transitioning to a new machine and the day before I spent some hours in the ER of my local hospital, and I missed it in the confusion.
In case you missed it on the main list, git-svn is *not safe* for histories within even three orders of magnitude of ggc's complexity. See http://esr.ibiblio.org/?p=6778 for the PSA I wrote last time I heard about an attempt to use it for an important conversion. Joseph Myers wrote: >ESR, can you give an update on the status of the conversion with >reposurgeon? You said "another serious attack on the repository >conversion is probably about two months out" in ><https://gcc.gnu.org/ml/gcc/2018-12/msg00112.html>. Is it on target to be >done by the time of the GNU Tools Cauldron in Montreal in September? I'd say that's about a 65% chance. Better than even, not high enough for me to make any hard promises. I just took delivery of a newer, faster surgical machine - an AMD Threadripper cranking 4.2Ghz on 64 hardware threads (thank you, System76 for the donation). I upgraded specifically to tackle the GCC problem. Early benchmarks on repocutter-in-Go suggest I'll get at least a 15x speedup relative to the Python version of reposurgeon, possibly rather more. That should reduce test conversion cycles to less than an hour, which ought to be fast enough that I can converge on a solution in reasonable time. The main source of uncertainty here is how long it will take me to finish the Go translation of reposurgeon. Once that's done I don't expect a finished conversion to take more than a couple of weeks to produce. The good news is the translation is now over 90% done; the bad news is that the part still pending includes the part you really care about, the Subversion dump interpreter. I realize this may not be the best place to ask, but the most effective way to speed things up would be to second me somebody with Go skills to help with finishing and debugging the translation. The blocker is not Go knowledge per se, it's the intrinsic complexity of the code I'm translating. Even with my skills and domain expertise this is a tough job. I will further add that a really motivated expert C programmer would do for the help. Go is an easy enough transition for a C expert that it would be practical to learn the language while assisting with this. >And, could you bring git://thyrsus.com/repositories/gcc-conversion.git up >to date with changes since Jan 2018, or push the latest version of that >repository to some other public hosting location? Done. https://gitlab.com/esr/gcc-conversion Interested parties here can have dev permissions if they like. > That repository >represents what I consider the collaboratively built consensus on such >things as the desired author map (including handling of the ambiguous >author name), which directories represent branches and tags, and what tags >should be kept or removed - but building up such a consensus and keeping >it up to date over time (for new committers etc.) requires that the public >repository actually reflects the latest version of the conversion >machinery, day by day as the consensus develops. Review of that >repository will be important for reviewing the details of whether the >conversion is being done as desired - the details of the machinery will >help suggest things to spot-check in a converted repository. I concur totally with that philosophy. (About that ER visit: I'll be OK. I have an injury called an osteochondral lesion in my right angle resulting from an ankle sprain in kung fu class, with arthroscopic surgery scheduled to correct it in June. On the 15th my ankle gave out while I was cooking breakfast; I fell down and hit my head on a chair leg. A short but expensive visit to the ER later I had three staples in my scalp and an MRI showing no brain damage. That could have gone far worse; joke about this if you like but we should all be thankful that I happen to have a rather thicker, tougher skull than average.) -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>