On Sat, Jul 21, 2018 at 1:39 PM Eric S. Raymond <e...@grelber.thyrsus.com>
wrote:
>
> On Sat, Jul 21, 2018 at 09:26:10AM +0200, Richard Biener wrote:
> > Can you summarize what is wrong with our current git mirror which was IIRC
> > created by git-svn importing?
>
> git-svn tends to do subtle danage damage to the back history. See my PSA at
> http://esr.ibiblio.org/?p=6778
>
> Partial quote:
>
> The problem with git-svn as a full importer is that it is not robust in
> the presence
> of repository malformations and edge cases – and these are all too
> common, both as
> a result of operator errors and scar tissue left by previous conversions
> from CVS. If
> anyone on your project has ever done a plain cp rather than “svn cp” when
> creating a
> tag directory, or deleted a branch or tag and then recreated it, or
> otherwise
> offended against the gods of the Subversion data model, git-svn will
> cheerfully,
> silently seize on that flaw and amplify the hell out of it in your git
> translation.
>
>
> The result is likely to be a repository that looks just right enough at
> the head end
> to hide damage further back in the history. People often fail to notice
> this because
> they don’t actually spend much time looking at old revisions after a
> repository
> conversion – but on the rare occasions when history damage bites you it’s
> going to
> bite hard.
>
> Since I wrote that I have learned that git-svn full conversions also have a
> tendency
> to screw up the location of branch joins.
Ok, so let me ask whether you can currently convert trunk and gcc-{6,7,8}-branch
successfully, ignoring "merges" into them (shouldn't have happened). All other
branches can in theory be converted later if required, right?
Richard.
