This is the mail archive of the
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
Jeff Law <email@example.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
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:
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>