Re: New trial conversion

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

Daniel J Sebald <dan...@ie...>:
> On 10/23/2017 10:34 PM, Eric S. Raymond wrote:
> >Daniel J Sebald <dan...@ie...>:
> [snip]
> >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.

(I meant "go *down* quadratically".  Branches where te join point has moved
farther are harder to recover.)

> OK, I think I see now.  CVS treats individual files separately (not a
> snapshot of the whole file tree, as does git), so it is just a series of
> changes for individual files and whenever something is tagged, each file
> gets the tagged.  CVS doesn't really care where a branch took place, just
> the history of file changes (i.e., checkins).

That's correct.

Deducing a changeset structure from the individual file change histories
is *hard*, even when the metadata is all correct.

> So, if a file is renamed, the "searching-for-tags-regressively" rule is a
> bust because there may be a break in the continuity of the file as far as
> following back some branch to the main branch or any other branch it might
> have come from.

That's also correct.

> We aren't corrupting branches though, if I understand correctly, because it
> looks like reposurgeon just generates a big diff between the branches and
> "Import of beta 347".  (But I'm not sure how much faith I'd have in rebasing
> the git repo after the conversion.)  Basically, our goal is to minimize the
> diff-hunk distance between the start of a branch and some point along the
> main branch.  That should be very close to the original branch point.

Yes.

> Ethan, were all CVS branches originated from the main branch?  Or were some
> branches rooted from some non-main branch?

Ethan has answered this - 4.0 and onward were from trunk, before that unknown.
I can add that if we successfully reroot all those there will only be one other
branch left, the 3.7 one.

That one is strange.  It doesn't have the same root point as the others - in
fact the ascribed root point is right back at the beginning of the changeset
sequence.

> Of course, we can't search the whole history for the minimum diff-hunk
> distance between versions as that would take forever even by computer
> standards.  But we do have a pretty good initial guess based upon the dates
> of the first changeset in each branch.

Yes, that was my heuristic as well.

>                                 Let me write in the dates of the
> changeset alongside some of the info I posted last time:
> 
> Import of beta 347.
> Author: Lars Hecking<xxxxx@xxxxx>
> Author date: 6/23/98 9:11 AM
> Parent: Import of beta 346.
> [8/20/14 1:37 PM] Child: Start of separate branch for version 5 stable
> releases
> [11/21/11 11:26 PM] Child: Bump stable version to 4.6; patchlevel is "alpha"
> [5/30/09 7:30 PM] Child: Start branch for Release 4.4
> [10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
> [7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key
> presses.
> [1/14/99 8:13 AM] Child: Windows linestyle fix.
> 
> Looking at those dates, they all do seem to be about the correct year that
> such branches would have been made.
> 
> It sounds like you really don't want to dig into any code for this
> tag-regression code.  What info and what format would you need about the
> main branch so that you could force reposurgeon to accept the manual branch
> points?

I have everything I need.  This kind of branch surgery is one of the
operations reposurgeon was designed for.

> I would propose that we do the following for each of those branches above:
> 
> 1) Make side-by-side clones in different directories of the repository. (Or
> create side-by-side directories for CVS checkouts.)
> 
> 2) In one directory, checkout the version of the repository at the start of
> the branch, e.g., the changeset associated with "Windows linestyle fix.".
> 
> 3) In the second directory, checkout the version of the repository *master*
> branch +/-5 changesets from the date indicated with the changeset listed
> above, e.g., 1/14/99 8:13 AM.
> 
> 4) For each of those checkouts, somehow use the OS diff tool in a
> directory-vs-directory comparison to measure the number of differences,
> i.e., the distance between the two source trees for the given versions.
> 
> 5) Choose as the branch point the version in master branch that has the
> minimum distance.
> 
> Does that seem like a reasonable plan?

It's not only reasonable, it's very close to mine.   Main difference is that
in at leasrt one case (v5stable) we already know what the right branch point
is.

>                                      Is it just those six branches that
> I've listed, or are there more?

That's it.
-- 
		<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.