Tradeoffs in the quality of GCC's repository conversion

[Martin Liška]

On 5/19/19 2:48 PM, Eric S. Raymond wrote:
> Recent discussion of whether the GCC team can live with an absence
> of SVN references references in a converted repository is emblematic
> of a larger problem.

Hi.

First, can you please reply to the email conversation that's happening
on gcc-patches mailing list (Subject: Add scripts to convert GCC repo from SVN to Git).

> 
> In this and other respects, Martin Liška's a approach is a clever
> kluge that will produce a low-quality conversion. 

Can you please be more precise? Note the initiative is done by Maxim Kuvyrkov
and he's proposing to use git-svn. Is it what you mean? I only prepared
the author map from your repository and it's not yet decided whether to
apply it or not.

> I won't tell you
> not to go this route; it's your decision, and I cannot yet absolutely
> rule out the possibility that even with the Go translation of
> reposurgeon complete it is not a practical tool at this scale.
> 
> But I do urge you not to jump without thinking through the tradeoffs
> carefully.  It's a pretty classic speed-vs-quality decision.
> 
> When I get that translation done, I should be able to produce a
> conversion that can be demonstrated correct even near branches with
> confused metadata due to SVN operator errors, which is the big ugly
> case that ad-hoc approaches like mliska's basically cannot get right -
> they don't do enough global analysis to resolve the defects.

As it was mentioned multiple times. Most of the contributors are pretty
happy with current git mirror and can theoretically start with that as
a git repository that will replace the SVN.

Martin

> 
> It is unfortunately true that I don't know when I'll be able to do
> this.  I think the odds that I will in fact be able to are 85%-90%,
> but I can't predict a completion date.  The surrounding problems are
> genuinely hard, I'm working alone on this, and I have to spend a lot of
> my time on work that pays bills.> 
> Still...if you opt for a quick, inexact conversion, do it with your
> eyes open.  There will be a price for that choice later on when you
> trip over the defects that a naive approach not only doesn't fix but
> can actually amplify.
>