Let's clean up the recent stuff and hide old messy stuff under a rug

[sfeam <sf...@us...>]

On Sunday, 29 October 2017 14:01:15 Daniel J Sebald wrote:
> I've experimented with something called cvs2git, which I believe does a 
> pretty good job of constructing branches and merges, but has some 
> drawbacks. 

I think we are past the stage of looking for alternative conversion utilities.

Can't we just flatten everything prior to version 4.0 into a baseline
snapshot that is the root for everything subsequent to that?

I really don't see why anyone will ever need to modify or branch from
anything prior to 4.0.  The tarballs are good enough for historical 
reference.  I just don't see why anyone would care about the branch
structure of 3.4/3.5/3.7/3.8 now that it's 20 years done and over.

And if someone _does_ want the historical information for some reason
other than development going forward, they would do better to go back to
the archived cvs repository itself rather than having to deal with any
post-processing layers you might add now to make the cvs->git conversion
work.

I suggest that at this point the only issue worth spending more time
on is authorship attributions transferred from the ChangeLog series.
Once that is sorted out, let's call it a wrap.

	Ethan


> All I did was follow the instructions here: 
> http://cvs2svn.tigris.org/cvs2git.html 
> with the exception I had to create a link cvs2git-tmp to cvs2svn-tmp 
> because the program (based off cvs2svn) was erroring out when it 
> couldn't find the blob and dump files in a non-existent cvs2git-tmp 
> directory.  (Surely a bug in the version I have, maybe not present in 
> more recent releases.)  cvs2svn takes about forty five minutes to run 
> (creates a mondo blob file), so have something else to work on in the 
> meantime.
> 
> It's major drawbacks are:
> 
> 1) No corrected author info.
> 
> 2) All of the RCSid strings are replaced by empty string, e.g.,
> 
> diff -ur '--exclude=.git' /home/sebald/gnuplot/gnuplot/gnuplot/time.c 
> gnuplot/time.c
> --- /home/sebald/gnuplot/gnuplot/gnuplot/time.c	2017-10-28 
> 22:16:04.820853058 -0500
> +++ gnuplot/time.c	2017-10-28 22:18:35.340854531 -0500
> @@ -1,5 +1,5 @@
>   #ifndef lint
> -static char *RCSid = "$Id: time.c,v 1.5 1998/12/09 15:25:54 lhecking 
> Exp $";
> +static char *RCSid = "$Id$";
>   #endif
> 
> which makes it even worse than the differences I'm now seeing.
> 
> 3) It seems to get the tags at the start of the repository wrong, even 
> though the branches look correct.
> 
> 
> At least cvs2git is a good guide for branching, and I'm wondering if we 
> can use reposurgeon on the cvs-fast-export result to make the branching 
> match cvs2git.  (I did this last night.)
> 
> In contrast, I would summarize cvs-fast-export's deficiencies as follows:
> 
> 1) I think cvs-fast-export is getting hung up on the scenario by which 
> the "Initial import of beta340." branch is the exact same time as the 
> "Initial revision".  That is, all the files in the "Initial import of 
> beta340." group match "Initial revision" as follows (same time, and zero 
> lines difference):
> 
> ----------------------------
> revision 1.1
> date: 1998/04/15 19:16:47;  author: lhecking;  state: Exp;
> branches:  1.1.1;
> Initial revision
> ----------------------------
> revision 1.1.1.1
> date: 1998/04/15 19:16:47;  author: lhecking;  state: Exp;  lines: +0 -0
> Initial import of beta340.
> ----------------------------
> 
> I'm not quite sure how Lars managed that.  Nonetheless, the conversion 
> program has to pick a name to use here.  As does cvs2git, 
> cvs-fast-export picks "Initial import of beta340.".  But cvs2git 
> recognizes this is a branch (still no files) and then does "Import of 
> beta 343" (containing files) and merges back into the master branch with 
> a comment such as
> 
> "
> This commit was generated by cvs2svn to compensate for changes in r5, 
> which included commits to RCS files with non-trunk default branches.
> "
> 
> It does the same thing with "Import of beta 344.", "Import of beta 
> 345.", "Import of beta 346." and then later something from "Initial 
> import of beta340."  So, yes, it's complex and it is best to have the 
> cvs2git result handy to understand this, but it makes clear the system 
> Lars was using as described by HBB, i.e., vendor branches.  I'm 
> wondering if we can just use reposurgeon to reconstruct that series of 
> branches and merges.
> 
> What cvs-fast-export does do for those tricky utility-branches is put in 
> the extra *** empty log message *** probably because of the time span of 
> the cvs initial checkins.  (Recall, 1999 computers were much slower than 
> today, so the file time stamps are spread out over 30 seconds.  We need 
> a wide fuzz-factor and if Lars did some action immediately after that 
> first CVS creation command, something could get pulled into the first 
> collection.)  Anyway, somehow the *** empty log message *** appears to 
> adjust things, and for cvs-fast-export we get:
> 
> *** empty log message ***         (no files)
> Initial import of beta340.        (no files)
> *** empty log message ***         (has files)
> Initial import of beta340.        (deletes some of those files)
> Synthetic commit for tag BETA_340 (puts those files back in)
> Import of beta 343.               (mostly modifications)
> Synthetic commit for tag BETA_343 (adds files back in)
> *** empty log message ***         (master branch start, has files)
> Include stdfn.h.                  (adds just one file)
> 
> In contrast cvs2git has the following first changesets:
> 
> Initial import of beta340.        (no files)
> Import of beta 343.               (has files)
> This commit was manufactured by cvs2svn to create branch 'GNUPLOT_BETA'.
>                                    (has two files)
> Import of beta 344.               (all modifications)
> Import of beta 345.               (all modifications)
> Import of beta 346.               (all modifications)
> Import of beta 347.               (all modifications)
> This commit was generated by cvs2svn to compensate for changes in r2, 
> which included commits to RCS files with non-trunk default branches.
>                                    (no files)
> This commit was generated by cvs2svn to compensate for changes in r5, 
> which included commits to RCS files with non-trunk default branches.
>                                    (merge files into master branch)
> Include stdfn.h.                  (adds just one file)
> 
> The above cvs2git arrangement looks a lot like Eric's original 
> repository result, except that result was missing the merge back into 
> master branch.
> 
> So, the ./reconvert file.  I'm going to email Eric a diff file of the 
> changes I've made.
> 
> 1) I've restored all the tags and branches, at least for the time being, 
> so that I could compare cvs-fast-export to cvs2git with greater detail. 
> Honestly, my preference would be to keep all tags, and I'd prefer that 
> HBB and Ethan (et al.) have a chance to see the full repository in a git 
> viewer first (I recommend qgit for this) before deciding to cut things 
> out.  I like having the tags GNUPLOT_RELEASE_3_7_0, etc. and maybe 
> instead we could just add additional tags 3.7.0, etc. alongside the 
> original.
> 
> HBB and Ethan should be able to run Eric's ./reconvert script to 
> generate the repository (it's just one command), so there's no need to 
> post any new repository to SourceForge.  (And creating the cvs2git 
> version isn't too difficult either.  Just use as an input to cvs2git the 
> gnuplot-cvs directory created by Eric's ./reconvert script.)
> 
> 2) I used cvs2git's branch points in directives for reposurgeon.  (Yes, 
> stuff like
> 
> /Initial import of 3.6 beta340./ assign root37
> @min(/New file.$/),<root37> reparent --use-order --rebase
> 
> (My learning curve was understanding various syntax in order to create 
> singletons.)
> 
> 
> After having done the above, I find that tree-wise the two conversions 
> look similar, except for the first dozen changesets.  cvs2git has more 
> logical file changes at the rebased branch point: the diffs look 
> correct, but I suspect the difference at the start of the repo result in 
> other files being swept in.
> 
> Tag-wise, again very similar ("cvs2git created this branch for a tag", 
> etc. coincides well with "cvs-fast-export created this branch for a 
> tag").  However, I think cvs-fast-export is a little better at this at 
> the start of the repo than cvs2git.
> 
> And exact file matches between the two conversions is difficult because 
> cvs2git drops all the RCSid strings.  (We'll make sure all those things 
> are gone from the start of the new repo, which Eric may have already done.)
> 
> 
> 3) I commented out the pre-CVS archival changesets for the time being. 
> I think we should just concentrate on that initial dozen changesets (try 
> to match cvs2git more, I couldn't figure out how to add merges via 
> reposurgeon), and if we get those cleared up my hope is that it works 
> its way through the whole tree and fixes up the branches without the 
> need of shims.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta