public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Tradeoffs in the quality of GCC's repository conversion
@ 2019-05-19 12:48 Eric S. Raymond
  2019-05-19 15:52 ` Martin Liška
  0 siblings, 1 reply; 3+ messages in thread
From: Eric S. Raymond @ 2019-05-19 12:48 UTC (permalink / raw)
  To: gcc, Martin Liška

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.

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

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.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"The state calls its own violence `law', but that of the individual `crime'"
	-- Max Stirner

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Tradeoffs in the quality of GCC's repository conversion
  2019-05-19 12:48 Tradeoffs in the quality of GCC's repository conversion Eric S. Raymond
@ 2019-05-19 15:52 ` Martin Liška
  2019-05-19 17:37   ` Eric S. Raymond
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Liška @ 2019-05-19 15:52 UTC (permalink / raw)
  To: Eric S. Raymond, gcc

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.
> 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Tradeoffs in the quality of GCC's repository conversion
  2019-05-19 15:52 ` Martin Liška
@ 2019-05-19 17:37   ` Eric S. Raymond
  0 siblings, 0 replies; 3+ messages in thread
From: Eric S. Raymond @ 2019-05-19 17:37 UTC (permalink / raw)
  To: Martin Liška; +Cc: gcc

Martin Liška <mliska@suse.cz>:
> > 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?

Yes, sorry, I misunderstood a reference.

On the subject of git-svn, here is a public service announcement I wrote
in 2015:

http://esr.ibiblio.org/?p=6778

I'll subscribe to gcc-patches now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2019-05-19 17:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-19 12:48 Tradeoffs in the quality of GCC's repository conversion Eric S. Raymond
2019-05-19 15:52 ` Martin Liška
2019-05-19 17:37   ` Eric S. Raymond

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).