Re: The first repository branch, "Windows linestyle fix."

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

I've experimented with something called cvs2git, which I believe does a 
pretty good job of constructing branches and merges, but has some 
drawbacks.  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