Re: Proposal for the transition timetable for the move to GIT

[Alexandre Oliva <oliva@gnu.org>]

On Dec 25, 2019, "Eric S. Raymond" <esr@thyrsus.com> wrote:

> Reposurgeon has a reparent command.  If you have determined that a
> branch is detached or has an incorrect attachment point, patching the
> metadata of the root node to fix that is very easy.

Thanks, I see how that can enable a missed branch to be converted and
added incrementally to a converted repo even after it went live, at
least as long as there aren't subsequent merges from a converted branch
to the missed one.  I don't quite see how this helps if there are,
though.

> If you're talking about a commit-by-commit comparison between two
> conversions that assumes one or te other is correct

Yeah, minus the assumption; the point would be to find errors in either
one, maybe even in both.  With git, given that the converted trees
should look the same, at least the tree diffs would likely be pretty
fast, since the top-level dir blobs are likely to be identical even if
the commits don't share the same hash, right?  And, should they differ,
a bisection to find the divergence point should be very fast too.

Could make it a requirement that at least the commits associated with
head branches and published tags compare equal in both conversions, or
that differences are known, understood and accepted, before we switch
over to either one?  Going over all corresponding commits might be too
much, but at least a representative random sample would be desirable to
check IMHO.

Of course, besides checking trees, it would be nice to compare metadata
as well.  Alas, the more either conversion diverges from the raw
metadata in svn, the harder it becomes to mechanically ignore expected
differences and identify unexpected ones.  Unless both conversions agree
on transformations to make, such metadata fixes end up conflicting with
the (proposed) goal of enabling mechanical verification of the
conversion results against each other.


> Well, except for split commits. That one would be solvable, albeit
> painful.

Even for split SVN commits, that will amount to at most one GIT commit
per GIT branch/tag, no?  That extra info should make it easy to identify
corresponding GIT commits between two conversions, so as to compare
trees, metadata and DAGs.

> The real problem here would be mergeinfo links.

*nod*.  I don't consider this all that important, considering that GIT
doesn't keep track of cherry-picks at all.  On the same note, it's nice
to identify merges, but since the info is NOT readily available in SVN,
it's arguably not essential that a SVN merge commit be represented as a
GIT merge commit rather than as multi cherry picking, at least provided
that merge metadata is somehow preserved/mapped across the conversion,
perhaps as GIT annotations or so.

I suppose if there are active branches that get merges frequently,
coming up with a merge parent that names at least the latest merged
commit would make the first merge after the transition a lot easier.

> There is another world of hurt lurking in "(disregarding expected
> differences)".  How do you know what differences to expect?

I was thinking someone would look at the differences, possibly
investigate a bit, and then decide whether they indicate a problem in
either conversion or something to be expected, ideally that could be
mechanically identified as expected in subsequent compares, until we
converge on a pair of conversions with only expected differences, if
any.

I suppose we're sort of doing that in a distributed but not very
organized fashion, as repos converted by both tools are made available
for assessment and verification.  Alas, the specification of expected
differences is not (to my knowledge) consolidated in a
publicly-available way, so there may be plenty of duplicate effort
filtering out differences that, if we organized the comparing effort by
sharing configuration data, scripts and tools to compare and to filter
out expected differences, we might be able to do that more efficiently.

-- 
Alexandre Oliva, freedom fighter   he/him   https://FSFLA.org/blogs/lxo
Free Software Evangelist           Stallman was right, but he's left :(
GNU Toolchain Engineer    FSMatrix: It was he who freed the first of us
FSF & FSFLA board member                The Savior shall return (true);