Martin Langhoff <martin.langh...@gmail.com>:
> On Thu, Dec 12, 2013 at 6:04 PM, Eric S. Raymond <e...@thyrsus.com> wrote:
> > I'm not sure what counts as a nonsensical branching point. I do know that
> > Keith left this rather cryptic note in a REAME:
> Keith names exactly what we are talking about.
Oh, yeah, I figured that much out. What I wasn't clear on was (a) whether
that's a complete description of "nonsensical branching point" or whether there
are other pathologies fundamentally *different* from that one.
I'm also not sure I have the end state of what cvs-fast-export does in that
case visualized correctly. When he says: "an entirely disjoint history will
be created containing the branch revisions and all parents back to the
root", I'm visualizing something like this:
Suppose the root is a our pathological branch point is at d, then it
sounds like he's saying cvs-fast-export will produce a changeset DAG
that looks like this:
What I'm not clear on here is how b is related to b' and b'', c to c' and c'',
and d to d' and d''. Which file changes go to which commit? I shall have to
craft some broken RCS files to find out.
Have I explained that I'm building a test suite? I intend to know exactly
what the tool does in these cases and document it.
> Between my earlier explanation and Keith's notes it should be clear to
> you. It is absolutely trivial in CVS to have an "inconsistent"
> checkout (for example, if you switch branch with the -l parameter
> disabling recursion, or if you accidentally switch branch in a
That last one sounds easy to fall into and nasty.
> On that inconsistent checkout, nothing prevents you from tagging it,
> nor from creating a new branch.
> An importer with a 'consistent tree mentality' will look at the
> files/revs involved in that tag (or branching point) and find no tree
> to match.
> CVS repos with that crap exist. x11/xorg did (Jim Gettys challenged me
> to try importing it at an LCA, after the Bazaar NG folks passed on
> it). Mozilla did as well.
> IMHO it is a valid path to skip importing the tag/branch. As long as
> main dev work was in HEAD, things end up ok (which goes back to my
> flying fish notes).
The other way to handle it would be to translate the history as though every
branch of a file subset had been an attempt to branch eveything.
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html