Alexandre Oliva <ol...@gnu.org>:
> I don't see that it does (help). Incremental conversion of a missed
> branch should include the very same parent links that the conversion of
> the entire repo would, just linking to the proper commits in the adopted
> conversion. git-svn can do that incrementally, after the fact; I'm not
> sure whether either conversion tool we're contemplating does, but being
> able to undertake such recovery seems like a desirable feature to me.
It's all in what you have in the lift script. Reposurgeon can do any kind
of branch surgery you want, and that can be added to the conversion pipeline
and replicated every time.
> >From what I read, he's doing verifications against SVN. What I'm
> suggesting, at this final stage, is for us to do verify one git
> converted repo against the other.
There are no tools for that, and probably won't be unless somebody
revives repodiffer. There isn't a lot of time left in the schedule for
that, and I have my hands full fixing other glitches. (Minor issues
about parsing ChangeLogs and generated .gitignores; the serious
problems are well behind us at this point.)
> Maxim appears to be doing so and finding (easy-to-fix) problems in the
> reposurgeon conversion; it would be nice for reposurgeon folks to
> reciprocate and maybe even point out problems in the gcc-pretty
> conversion, if they can find any, otherwise the allegations of
> unsuitability of the tools would have to be taken on blind faith.
Joseph has already made the call to go with a reposurgeon-based
conversion for reasons he explained in detail on this list. Given
that, it really doesn't make any sense for me to do any of what
you're proposing with time I could use working on Joseph's RFEs
instead.
If you're concerned about the quality of reposurgeon's conversion,
you'd be a good person to work on a comparison tool. Should I email you
a copy of the repodiffer code as it last existed in my repository?
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
