Re: New trial conversion

[Daniel J S. <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.

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).

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.

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.

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

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.  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 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?  Is it just those six branches 
that I've listed, or are there more?

Dan