Jeff Law <l...@redhat.com>: > But it's not that freshly constructed, at least not in my mind. All > the experience ESR has from the python implementation carries to the Go > implementation.
Not only do you have reposurgeon, you have me. I wish this mattered less than it does. I have *far* more experience doing big, messy repository moves than anybody else. I try to exteriorize that knowledge into the reposurgeon code and documents as much as I can, but as with other kinds of expertise a lot of it is implicit knowledge that is only elicited by practice and answering questions. On small conversions of clean repositories such implicit expertise doesn't matter too much. You may be able to pull off a once-and-done with the tools, especially if they're my tools and you've read all my stuff on good practice. As an example, the CVS-to-git conversion of groff didn't really need me. Lifts from CVS are normally horrible, but the groff devs were the best I've ever seen at not leaving debris from operator errors in the history. Any of them could have read my docs and done a clean coversion in two hours. Only...there was no way to way to know that in advance. The odds were heavily against it. Emacs was, and GCC is, the messy opposite case. You guys needed a seasoned "I know these things so you don't have to" expert more than you will probably ever really understand. And, sadly, there aren't any others but me yet. Nobody else has been interested enough in the problem to invest the time. > Where I think we could have done better would have been to get more > concrete detail from ESR about the problems with git-svn. That was > never forthcoming and it's a disappointment. Maybe some of the recent > discussions are in fact related to these issues and I simply missed > that point. I posted this link before: http://esr.ibiblio.org/?p=6778 I can't actually tell you much more than that. Actually, if I understood git-svn's failure modes in enough detail to tell you more I might be less frightened of it. Mostly what I know is that during several other conversions I have stumbled across trails of metadata damage for which use of git-svn seems to have been to blame. Though, admittedly, I'm not certain of that in any individual case; the ways git-svn screws up are not necessarily disinguishable from the aftereffects of cvs2svn conversion damage, or from normal kinds of operator error. Overall, though, defect rates seemed noticeably higher when git-svn had been used as a front end. I learned to flinch when people wanting me to do a full conversion of an SVN repo admitted git-svn had been deployed, even though I was hard-put to explain why I was flinching. > I do think we've gotten some details about the "scar tissue" from the > cvs->svn transition as well as some of our branch problems. It's my > understanding reposurgeon cleans this up significantly whereas Maxim's > scripts don't touch this stuff IIUC. That's correct. And again, no blame to Maxim for this; he took a conventional approach that does as little analysis as it can get away with, which can be a good tradeoff on smaller, cleaner repositories without a CVS back-history. > There's still > work going on, but I'd consider the outstanding issues nits and well > within the scope of what can reasonably still be changing. Issue list here: https://gitlab.com/esr/reposurgeon/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=GCC Presently 6 items including 2 bugs. One of those bugs may already be fixed, we're waiting on Joseph's current conversion to see. Counting time do all the RFEs requested, polishing, and final review I think we're looking at another week, maybe a bit less if things go well. You guys could get a final conversion under your Yule tree. -- <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
