Re: One branchpoint discrepancy

[Daniel J S. <dan...@ie...>]

On 10/30/2017 12:09 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
[snip]
>> The interesting thing is that just like cvs2git, cvs-fast-export chose to
>> tag
>>
>> [gnuplot-4-6-alpha]  update Bruce Ravel's contact info
>>
>> but failed to make that branch connection.  Anyway, this necessitates the
>> attached change to ./reconvert.
>>
>> Dan
> 
> Thanks, applied to my reconvert master.

OK, thanks.

I'm pretty sure the one major thing we have to resolve is this group of 
CVS checkins at the very start of the repository.  All those changes 
have to be merged into the master branch.  If we can address that, all 
will work out with no need for adjustments.

I'd sort of like to put effort into the right place.  I've cloned the 
cvs-fast-export utility and I'm willing to help on matters, so if its 
possible I wonder if we could enhance the merging aspect of that utility.

Yes, there is a bit of ambiguity in merges with CVS, it just isn't 100% 
accurate to identify exactly what the programmer had checked out when 
compiling and subsequently did a checkin.  But I can see the logic that 
cvs2git is following and there is some sense to it.

RULE: Basically, a merge should be declared whenever a symbol that is 
assigned to a higher-level branch (let's say trunk) references a version 
number that is associated with a lower-level branch.  Let's use 
gnuplot.rot as an example, as that is the one that Eric has applied a 
shim for.  The change associated with that shim is version 1.1.1.2:

1.1.1.2
log
@Import of beta 344.
@
text
@a0 6
# HBB: revised open-ended animation routine. Used to just turn
etc.

OK, so let's look at the CVS gnuplot.rot,v file for the symbols and 
version 1.1.1.2.  I'm including a screenshot of the qgit display of 
cvs-fast-export's output at that important would-be merge point.  Here 
are the contiguous three symbols in which 1.1.1.2 first appears, from 
the gnuplot.rog,v file:

	BETA_344_989422:1.1.1.2
	BETA_344:1.1.1.2
	BETA_343_980416:1.1.1.1

Refer to the screenshot, and notice that BETA_344 is associated with the 
branch (red), and then the first symbol after that which references 
1.1.1.2 and *appears in the trunk* (look at the screenshot, black) is 
the synthetic commit BETA_344_989422:1.1.1.2.  OK, so by the rule listed 
above, this should be declared a merge.  Now, gnuplot.rot is not the 
only file that falls in this changeset, as there are probably several 
other files in which a branch is first referenced by BETA_344_989422.

There might be some ambiguity about the state of other files at this 
point, but I would say simply recall the BETA_344_989422 state from CVS 
and call that the state for the merge and generate all git diffs 
accordingly, perhaps that's not the exact methodology.  But the general 
idea is those changes from the branch have to get merged in at some 
point if they are used by the trunk, and their first use in the trunk is 
the logical place to create a merge.  (Furthermore, in this case, but 
not of general relevance, is the fact that the comments for changesets 
surrounding BETA_344_989422 suggest that indeed things are being "merged".)

So, to summarize, looking at that screenshot PNG, we should have a merge 
connecting BETA_344 (the first reference to gnuplot.rot's 1.1.1.2 in the 
*branch*) to BETA_344_989422 (the first reference to gnuplot.rot's 
1.1.1.2 in the *trunk*).  That merge might sweep in other files, but 
whenever the rule hypothesis for any file appears, there has to be a merge.

I'll be away for most of the day, but think over the amount of effort it 
would be to address this in cvs-fast-export source code.  I'm willing to 
help if I can.  Otherwise, maybe there is some other creative way in 
reposurgeon to force a merge of the branch modifications.  (For example, 
I imagined rebasing the master on top of that red branch with Import XYZ 
changesets, but again that's effort that really isn't the best way to 
solve this.)

Dan