On Sun, May 19, 2019 at 8:50 PM Eric S. Raymond <e...@thyrsus.com> wrote: > > 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
There's not many details there but I always thought that the "interesting" parts of the GCC history (official branches and trunk) do _not_ contain merge commits so the GCC history forms a tree rather than a DAG. (I'm not sure if there's an easy way to verify whether there are any merge commits on a specific branch) That should make the conversion result immune to the partial merge issue (the only specific issue I found googling for issues of SVN to git conversions). In fact a conversion side-stepping git-svn and using a brute-force check out revs in order and commit should preserve everything interesting (for official branches). There's the few cases where we deleted trunk to skip of course. There may be merges hidden inside the cvs2svn converted part as well as in user branches (definitely merges from trunk to branch). But at least it is policy to not use merges to push things to trunk or branches but cherry pick using patches. Richard. > 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> > >
