Re: New trial conversion

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> Anyway, the big question for me is (looking at the qgit graph display, where
> this is obvious) why do (tag, but no branch name) 3.7.3, branch-4-0-stable,
> branch-4-2-stable, branch-4-4-stable, branch-4-6-stable, and
> branch-5-0-stable all spring from
> ??
> 
> It looks to me as though all these imports of "Initial import of beta340.",
> "Initial import of beta340." (listed a second time for some reason), "Import
> of beta 343.", "Import of beta 344.", "Import of beta 345.", "Import of beta
> 346.", "Import of beta 347." correspond to the branches in some way, but for
> some reason these are all being tied back to the same date/time when perhaps
> they should be dispersed throughout the tree at times more in line with when
> those branches were created in CVS.  Is this a bug?  Is this the missing
> info that we need to make a guess at?

I tried to explain this before.  It's so confusing that I don't blame anyone
for having missed or misunderstood the explanation.

The way CVS does tags is by propagating an instance of the tag to every
master in the repository.  One *kind* of tag designates the root node
of a branch.  When all goes well, these sets of tags begin - and remain
- complete. That is, every master is tagged.

Sometimes, due to one of CVS's ninety-kajillion bugs - or perhaps due to
a quantum fluctuation in some Schrodinger's box somewhere - a tag set is
created incompletely, or a complete tag loses one of its marbles.  This
especially likely if you do dangerous things to the repository. Dangerous
things include deleting or - worse - attempting to rename files.

Incomplete tag sets are like bombs waiting to go off.  If you do nothing but
checkouts at branch heads, you may never notice they're broken - though the
consequences can include incomplete checkouts at tags, and *projects have
been sunk this way*.

Now you run cvs-fast-export on your repo.  It's trying to deduce a
changeset graph. It really, really wants to only deal with complete
tag sets.  (Because incomplete tags sets are dangerous: see, incomplete
checkouts.)  The worst case, which we have struck here, is that the
tag identifying a branch root node is incomplete.

It is kind of murky what happens next; there is not anyone, including me,
who completely understands the core code in cvs-fast-export.  The person
who wrote it, Keith Packard (the X guy) has forgotten.

What seems to happen is that the code starts replicating changesets at the
base of the branch, moving the join point backward until it can identify a
common ancestor node that has a complete tag set.  Often this is quite far
back.

This crazy graph:

redroot ---> redleft -> 4.0.2 -> branch52 --> b52left ---> master
   |                                |
   |                                +-------> b52right --> 5.2.0 --> 5.2.1
   +-------> redright -+
                       |
+----------------------+
|
+-> greenroot ---> greenright ---> 3.7.1 --> 3.7.2  --> 3.7.3
        |
        |
+-------+
|
+-> v5stable -> 5.0.[01234567] -> branch-5.0-stable
|
+-> bump46 -> 4.6.[0123456] -> branch 4.6-stable
|
+-> start44 -> 4.4.[01] -> 4.4.[34] -> branch-4.4-stable
|
+-> jump42 -> 4.2.[123456] -> branch-4.2-stable
|
+-> greenbug -> branch-4.0-stable

is a result of several waves of branches getting rooted *way* further back
in the tree than they ought to because there was only an incomplete branch root
tag where the actual branch should have been.

Or something like that. The failure nodes from damaged CVS metadata are so
%$^#% complicated and obscure that even I, who am the world's &#$@$#@! expert
on this problem, don't completely understand them.  Seriously.  It's a minor
miracle that CVS works at all, and a major miracle that cvs-fast-export does.

The way to fix this kind of problem is to identify the original root points
for each branch and regraft them there. If you're very good and very lucky,
the rerooted branch's content at head will match what it was supposed to in
CVS and you won't have to throw it away.

Odds that you can salvage a branch go up quadratically in how far back the
original root point.  I'm fairly confident about v5stable, more doubtful
about any of the others.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.