Re: Repo conversion troubles.

[Jeff Law <law@redhat.com>]

On 07/09/2018 01:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly.  This time I have mismatches in the following
> files.
> 
> libtool.m4
> libvtv/ChangeLog
> libvtv/configure
> libvtv/testsuite/lib/libvtv.exp
> ltmain.sh
> lto-plugin/ChangeLog
> lto-plugin/configure
> lto-plugin/lto-plugin.c
> MAINTAINERS
> maintainer-scripts/ChangeLog
> maintainer-scripts/crontab
> maintainer-scripts/gcc_release
> Makefile.def
> Makefile.in
> Makefile.tpl
> zlib/configure
> zlib/configure.ac
> 
> Now I'll explain what this means and why it's a serious problem.
[ ... ]
That's weird -- let's take maintainer-scripts/crontab as our victim.
That file (according to the git mirror) has only changed on the trunk 3
times in the last year.  They're all changes from Jakub and none look
unusual at all.  Just trivial looking updates.

libvtv.exp is another interesting file.  It changed twice in early May
of this year.  Prior to that it hadn't changed since 2015.


[ ... ]

> 
> There are brute-force ways to pin down such malformations, but none of
> them are practical at the huge scale of this repository.  The main
> problem here wouldn't reposurgeon itself but the fact that Subversion
> checkouts on a repo this large are very slow. I've seen a single one
> take 12 hours; an attempt at a whole bisection run to pin down the
> divergence point on trunk would therefore probably cost log2 of the
> commit length times that, or about 18 days.
I'm not aware of any such merges, but any that occurred most likely
happened after mid-April when the trunk was re-opened for development.

I'm assuming that it's only work that merges onto the trunk that's
potentially problematical here.

> 
> So...does that list of changed files look familar to anyone?  If we can
> identify the revision number of the bad commit, the odds of being able
> to unscramble this mess go way up.  They still aren't good, not when
> merely loading the repository for examination takes over four hours,
> but they would way better than if I were starting from zero.
They're familiar only in the sense that I know what those files are :-)

Jeff