Proposal for the transition timetable for the move to GIT

[Sandra Loosemore]

On 12/6/19 12:46 PM, Eric S. Raymond wrote:
> Richard Biener <richard.guenther@gmail.com>:
>> To me, looking from the outside, the talks about reposurgeon doing damage and a rewrite (in the last minute) would fix it doesn't make a trustworthy appearance either ;)
> 
> *shrug* Hard problems are hard.
> 
> Every time I do a conversion that is at a record size I have to
> rebuild parts of the analyzer, because the problem domain is seriously
> gnarly. I'm having to rebuild more than usual this time because the
> GCC repo is a monster that stresses the analyzer in particularly
> unusual ways.
> 
> Reposurgeon has been used for several major conversions, including groff and Emacs.
> I don't mean to be nasty to Maxim, but I have not yet seen *anybody* who thought they
> could get the job done with ad-hoc scripts turn out to be correct.  Unfortunately,
> the costs of failure are often well-hidden problems in the converted history
> that people trip over months and years later.
> 
> Experience matters at this.  So does staying away from tools like git-svn that
> are known to be bad.

I have nothing useful to contribute regarding the actual mechanics of 
the repository conversion (I'm a total dummy about the internals of both 
git and svn and stick with only the most basic usages in my daily work), 
but from a software engineering and project management perspective....

I'm also put off by the talk of having to do last-minute rewrites of a 
massively complex project.  [Insert image of prehistoric animals trapped 
in tar pit here.]  Shouldn't it be possible to *test* whether Maxim's 
git-svn conversion is correct, e.g. by diffing the git and svn versions 
at appropriate places in the history, or comparing revision histories of 
each file at branch tips, or something like that?  Instead of just 
asserting that it's full of bugs, without any evidence either way?  I'd 
expect that the same testing would need to be performed on the 
reposurgeon version in order to have any confidence that it is any less 
buggy.  Do we have any volunteers who could independently work on QA of 
whatever git repository we end up with?

-Sandra