Re: Roundup of GNUPLOT conversion issues

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

On 10/29/2017 12:30 AM, Eric S. Raymond wrote:
> The latest GNUPLOT conversion-machinery tarball, available as usual at
> 
>      wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz
> 
> cleans up a number of minor issues, including:
> 
> (1) Patching out CVS release numbers in comments.
> 
> (2) Better explanatory text and comments for the very early section of
> the repository.
> 
> (3) Patch that incorrect author date due to a ChangeLog typo.
> 
> I shall round up my responses to all recent traffic and then propose
> what to do next.

I've been making some ./reconvert mods, supplying all the branch points 
as determined with cvs2git.  However, the branches at the start of the 
repository for importing beta340, etc. are going to need some work on 
your part.

I'll describe in a follow-up email.  But wait for me to get a diff file 
to you and we can put my mods in place.


> Bastian Märkisch:
>> Unfortunately, the last problem we discussed is not solved, though:
>> If there's an insertion into the ChangeLog below an existing author line,
>> the current algorithm picks the author line _below_ instead of the one
>> _above_. This happens quite frequently and currently still leads to hundreds
>> of wrong attributions.
>> For examples try:
>>   git log --author=Ethan --committer=Bastian --oneline | wc -l
> 
> I still need an example pair of Changelogs with a difference that
> triggers this bug. Given that, I can (a) fix the bug, and (b) add it
> to my regression tedt so we can be certain it does not recur.
> 
> Daniel Sebald, Fri Oct 27 12:50:51 2017
>>                                                    These files with the
>> wrong RCSid and the demo-file discrepancies and the backward-progressing
>> copyright dates reside in the master branch *until* some changeset resolves
>> them.  In the case of 3.7.x branch, there are a hundred "corrupted" files
>> still, but shortly after 3.7.0 was completed there was a mass restructuring
>> which moved files like alloc.c to a new subdirectory.  That action resulted in
>> the correct files going forward, such that 4.x and 5.x series all match
>> well...except for the 4.0 shim that Eric noted, probably a vestige still of
>> what I described.
> 
>> So, we need to go back to the start of the repository and make sure those
>> first few commits, the "Import of beta 340", etc. are done properly such that
>> something like the following set of files all match in terms of stamped
>> revisions and branches:
> 
>> How should we proceed Eric?
> 
> What I'm hearing is, exact for the demo shim I added, all the remaining
> differences early in branches other than 3.7.x are incorrect RCS IDs.
> 
> What I think is that trying to get the RCS IDs perfect would be wasted
> effort.  One of my last patches removes all of those, anyway.  It's
> time to remember that the purpose of the repository transition is to
> support development going forward, not to have a theoretically perfect
> and literal transcription of the CVS history.

I'm interested in retaining history.  Why shape it into a different 
history that no one is familiar with?  I'm fine with the RCS IDs not 
matching--Ethan (with my help), can branch a stub off of a release with 
bad RCS IDs and then put in the actual release code.  That will then 
produce the actual release code in the repository--for the price of just 
a few diffs.


> We wouldn't even *want* that kind of 'perfection' - the old-style
> change comments wouldn't play well with git log, for one thing.

Projects like Octave use FSF format

http://hg.savannah.gnu.org/hgweb/octave/rev/1680d425bb38

and it produces a nice log which highlights with color in the pager.


> Hans-Bernhard Bröker <HBB...@t-...>:
>>> On the other hand, I'm not getting
>>> a good feeling from Dan's reports on his attempts to disentangle that branch.
>>> We know it's corrupt - doesn't have the right tip state.
>>
>> I'm not quite convinced Dan's analysis is correct.  The branch isn't
>> corrupt, it was just set up somewhat strangely at the time.
> 
> It's corrupt in the sense that because of the vendor-branch confusion we
> not only can't guarantee that the gitspace sequence of commits really
> matches the CVS development history, we can't even get the right tip
> state out of the conversion.

cvs2git seems to handle the vendor-branch via a branch-and-merge 
approach.  (It only goes for a year or so, right?)  We'll come back to 
this, as I think it is the missing piece we need to deal with still.


> The extent to which this is a CVS problem versus a git problem versus
> a cvs-fast-export problem is really only of theoretical interest.
> 
> I've spent three weeks on this conversion and my patience for
> wandering further off into the weeds is evaporating.  It only
> lasted this long because getting ChangeLog analysis right seemed
> like a thing worth doing.

Yes, ChangeLog analysis is good.


> Can we please refocus on *finishing* this with changes that actually add
> value for forward development?

The only major thing still is that first dozen or so commits at the 
start.  I'm not sure, but that may be cvs-fast-export dependent. 
Otherwise, I'm getting the hang of reposurgeon and ./reconvert, so I can 
deal with verifying correctness of branches and rebuilding.


>> Vendor branches with other branches partially rooted in them cannot be
>> collapsed or ignored.  Nor can they be treated completely like ordinary
>> branches (or conversion tools would have been doing that since day one).
> 
> I know.  Vendor branches have been a huge pain in the ass on other
> conversions I've done, too.
> 
> Here is what I suggest we do:
> 
> 1. Drop the 3.7.x branch.  Replace it with a branch consisting of just
> the archived 3.7.[0123] trees in sequence (I now have them all).

This is more work than just moving the branch to the correct location. 
cvs2git has chosen the branch point that I deduced by version/dates 
within the files, i.e., "New file."  I'll work this out.


> 2. Fix any remaining deficiences in ChangeLog scanning if possible.
> 
> 3. Fill in the empty log comments that are left.

We'll see if Ethan wants to do this.  He and I can split the work, but 
only if it is something easy to do with reposurgeon.

Dan