gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Hans-Bernhard Bröker <HBB...@t-...>:
> Am 26.10.2017 um 00:18 schrieb Eric S. Raymond:
> >I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> >it on /#include gp_time.h/ yields this diff at the tip:
> >
> >--- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> >+++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> >@@ -1,12 +1,5 @@
> >-# HBB: revised open-ended animation routine. Used to just turn
> >-# round and round by somewhat large steps. Now, it tumbles
> >-# back and forth smoothly.
> >-# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> >-# many iterations (iteration_count=0 has to be set before this
> >-# script is called)
> >  zrot=(zrot+10)%360
> >  xrot=(xrot+17)%180
> >-set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> >+set view xrot,zrot
> >  replot
> >-iteration_count=iteration_count+1
> >-if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> >+reread
> 
> This might be a symptom of an actual problem in cvs-fast-export's handling
> of vendor branches, or at the very least of a significant functional
> limitation.
> 
> That diff is between two different revisions on the vendor branch (1.1.1.1
> and 1.1.1.2, a.k.a. "Initial import of beta340" and "Import of 344").
> Revision 1.1.1.2 is correct for all relased tags since 3.7.0, but I suspect
> the general plan of "what happens on a vendor branch, stays on a vendor
> branch", fails here.

You are probably right.  Unfortunately this is one of those cases where
there are several mutually contradictory policies one could apply, each
right in some cases and wrong in others.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

[Hans-Bernhard B. <HBB...@t-...>]

Am 28.10.2017 um 01:01 schrieb Daniel J Sebald:
> On 10/27/2017 05:16 PM, Hans-Bernhard Bröker wrote:

> Agreed.  This is a consequence of reposurgeon choosing to place that 
> 3.7.x branch somewhere other than the trunk at (what I believe should be)

More to the point, it's a consequence of reposurgeon's underlying 
cvs-fast-export struggling with the strange CVS concept of a "vendor 
branch", with less than total success.

> Lars created that branch, 1.1.1, near the start but didn't use it for 
> much, apparently.  The branch-master is based on 1.1:

Not really.  That's a vendor branch, and it was used exactly as 
intended: to track an upstream or "vendor" series of releases while 
maintaining local changes.  In our case the upstream source was Lars' 
own CVS repository, and this practice ended when Lars switched over to 
SourceForge as his primary repository, 6 tracked "vendor" releases later.

In a way, that vendor branch is still in use today, 19 years later: some 
of our demo files are still on that vendor branch; their current CVS 
revision is 1.1.1.1.

On the surface, vendor branches can be viewed as CVS's attempted at 
implementing a modern-day DVCS, i.e. "cvs import" is a much dumber 
ancestor of "git pull". Internally, their handling is quite probably the 
weirdest aspect of CVS by quite a some margin.

> I confirmed there are no comments "# HBB: revised etc." in the master 
> branch which matches Lars' CVS repo.

And that's the source of this problem: cvs-fast-export tries to brush 
what happens on vendor branches under the carpet, mostly pretending that 
entire branch is just a single initial commit.

But in our case that's the wrong thing to do. Our early project branches 
start at different points along the vendor branch, at least for some of 
the files.  So it cannot work to squash the vendor branch into a single 
commit.  Either one branch gets files that are older than they should 
be, or another branch gets files that are newer than they should be.

Re: Update on the branch surgery

[Hans-Bernhard B. <HBB...@t-...>]

Am 27.10.2017 um 22:28 schrieb Eric S. Raymond:

> At leasr part of the problem is this sequence at the beginning:
> 
> c57b183 *** empty log message ***   <--- branch point
> e2e7fb8 Initial import of beta340.
> 
> That top commit is actually an import of 3.6 beta - I'll edit the comment
> to reflect that at some point.  Also that beta 340 is a 3.4.0 beta which
> should swap places with the 3.5 commit.  

That's really 3.6 beta340, one of a rather long series of releases 
called, by their full name, "pre-3.6 beta {number}", or just 
"beta{number}" for short.  These were maintained by Dave Denholm and 
Lars Hecking, in a non-public CVS.   Some important milestones in that 
sequence even got their own "patchlevel" sub-releases.

[BTW, I finally dug through my collection of old HDs and found quite a 
number of them as tarballs, e.g. betas 178, 213, 231, 340 and 347, and 
also an apparently genuine 3.7.0].

Number 340 in that series became the start of our CVS repository, as the 
initial vendor branch import.  Betas 343,344,345,346 and 347 were 
imported onto the vendor branch, then Lars stopped using his private 
repository, so there was no further use of the vendor branch.

Re: Update on the branch surgery

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

On 10/27/2017 05:16 PM, Hans-Bernhard Bröker wrote:
> Am 26.10.2017 um 00:18 schrieb Eric S. Raymond:
>> I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
>> it on /#include gp_time.h/ yields this diff at the tip:
>>
>> --- a/demo/gnuplot.rot    1998-04-22 09:38:42.000000000 -0400
>> +++ b/demo/gnuplot.rot    2017-10-25 17:39:55.083147765 -0400
>> @@ -1,12 +1,5 @@
>> -# HBB: revised open-ended animation routine. Used to just turn
>> -# round and round by somewhat large steps. Now, it tumbles
>> -# back and forth smoothly.
>> -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
>> -# many iterations (iteration_count=0 has to be set before this
>> -# script is called)
>>   zrot=(zrot+10)%360
>>   xrot=(xrot+17)%180
>> -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
>> +set view xrot,zrot
>>   replot
>> -iteration_count=iteration_count+1
>> -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
>> +reread
> 
> This might be a symptom of an actual problem in cvs-fast-export's 
> handling of vendor branches, or at the very least of a significant 
> functional limitation.
> 
> That diff is between two different revisions on the vendor branch 
> (1.1.1.1 and 1.1.1.2, a.k.a. "Initial import of beta340" and "Import of 
> 344").  Revision 1.1.1.2 is correct for all relased tags since 3.7.0, 
> but I suspect the general plan of "what happens on a vendor branch, 
> stays on a vendor branch", fails here.

Agreed.  This is a consequence of reposurgeon choosing to place that 
3.7.x branch somewhere other than the trunk at (what I believe should be)

Date:   Thu Jan 14 19:35:52 1999 +0000
     New file.

Lars created that branch, 1.1.1, near the start but didn't use it for 
much, apparently.  The branch-master is based on 1.1:

----------------------------
revision 1.1
date: 1998/04/15 19:16:41;  author: lhecking;  state: Exp;
branches:  1.1.1;
Initial revision
----------------------------

I confirmed there are no comments "# HBB: revised etc." in the master 
branch which matches Lars' CVS repo.

So there are two things going on, basically the same principle.  Some 
differences in branch-3.7.7 hang around if rebasing after the fact. Some 
differences at the very beginning of the master branch get propagated. 
When we compare across the two branches trying to find the graft 
location for 3.7.x series, its a combination of differences.

Can Reposurgeon force branch points at the start, as opposed to doing 
rebasing?

Dan

Re: Update on the branch surgery

[Hans-Bernhard B. <HBB...@t-...>]

Am 26.10.2017 um 00:18 schrieb Eric S. Raymond:
> I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> it on /#include gp_time.h/ yields this diff at the tip:
> 
> --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> @@ -1,12 +1,5 @@
> -# HBB: revised open-ended animation routine. Used to just turn
> -# round and round by somewhat large steps. Now, it tumbles
> -# back and forth smoothly.
> -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> -# many iterations (iteration_count=0 has to be set before this
> -# script is called)
>   zrot=(zrot+10)%360
>   xrot=(xrot+17)%180
> -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> +set view xrot,zrot
>   replot
> -iteration_count=iteration_count+1
> -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> +reread

This might be a symptom of an actual problem in cvs-fast-export's 
handling of vendor branches, or at the very least of a significant 
functional limitation.

That diff is between two different revisions on the vendor branch 
(1.1.1.1 and 1.1.1.2, a.k.a. "Initial import of beta340" and "Import of 
344").  Revision 1.1.1.2 is correct for all relased tags since 3.7.0, 
but I suspect the general plan of "what happens on a vendor branch, 
stays on a vendor branch", fails here.

Re: Update on the branch surgery

[Petr M. <mi...@ph...>]

Those "beta 3xy" are patchlevels of gnuplot 3.6, not patchlevels of gnuplot 
3.4.

I've found some my old OS/2 patches, wherefrom I can see that:
- gnuplot 3.6 beta 336 was available in April 1997
- gnuplot 3.6 beta 340 was available in April 1998

Petr


> That top commit is actually an import of 3.6 beta - I'll edit the comment
> to reflect that at some point.  Also that beta 340 is a 3.4.0 beta which
> should swap places with the 3.5 commit.  3.7. branches off from c57b183.
>
> The real problem, I think, is the early 3.7 commits:
>
> e30004 Rewrite option handling and use execvp() instead of execl().
> ad4911d Windows linestyle fix.
> cccd8de Import of beta 347.
> 9a208db Import of beta 346.
> 0a418be Import of beta 345.
> 7c5413c Import of beta 344.
> 78d32b1 Import of beta 343.
> 00d2bf2 Initial import of beta340.
> c57b183 *** empty log message ***   <--- branch point
>
> Internally all of those up to 347 actually predate the 3.6 beta. I think this
> is where your weird RCS IDs - and probably other divergences - are coming from.
> I'm thinking about making a conversio with those commits (especially the dubious
> re-import of 3.4.0) ripped out.

Re: Update on the branch surgery

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

On 10/27/2017 03:28 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
[snip]
>> That drd RCSid (and a lot of the copyright notices...no wonder they are
>> going backward from 1999 to 1998) must be coming from prior to the start of
>> this CVS.  I'm going to guess that drd, et al. were using a different CVS
>> repository prior to the start for which there *was* a version 1.11 of this
>> file.  But then Lars started a new one.
>>
>> OK, so the current git repository on sourceforge has a problem at the very
>> onset that is propagated throughout the whole master branch.  It's that
>> issue with the branch point of master we discussed previously.  I'm going to
>> need a recent git repository, but I think I've found the 3.7.0 version
>> location and I'm pretty sure we'll be in good shape if we get that initial
>> series of imports and branches correct.
> 
> At leasr part of the problem is this sequence at the beginning:
> 
> c57b183 *** empty log message ***   <--- branch point
> e2e7fb8 Initial import of beta340.
> 73285bb Content from historic/gnuplot-3.5.tar.gz
> cdd7d69 Content from historic/gnuplot-3.2.tar.gz
> 6070b01 Content from historic/gnuplot-3.1.tar.gz
> 605e727 Content from historic/gnuplot-3.0.tar.gz
> 6bc888c Content from historic/gnuplot-2.0.tar.gz
> 55fe23a Content from historic/gnuplot-1.10A.tar.gz
> e56802d Content from historic/gnuplot-1.1.tar.gz
> 
> That top commit is actually an import of 3.6 beta - I'll edit the comment
> to reflect that at some point.  Also that beta 340 is a 3.4.0 beta which
> should swap places with the 3.5 commit.  3.7. branches off from c57b183.
> 
> The real problem, I think, is the early 3.7 commits:
> 
> e30004 Rewrite option handling and use execvp() instead of execl().
> ad4911d Windows linestyle fix.
> cccd8de Import of beta 347.
> 9a208db Import of beta 346.
> 0a418be Import of beta 345.
> 7c5413c Import of beta 344.
> 78d32b1 Import of beta 343.
> 00d2bf2 Initial import of beta340.
> c57b183 *** empty log message ***   <--- branch point
> 
> Internally all of those up to 347 actually predate the 3.6 beta. I think this
> is where your weird RCS IDs - and probably other divergences - are coming from.
> I'm thinking about making a conversio with those commits (especially the dubious
> re-import of 3.4.0) ripped out.

I'm pretty sure it is the very beginning of the git translation.  In a 
previous post I sent this difference:

=============================================================================
RCS file: /cvsroot/gnuplot/gnuplot/Attic/alloc.c,v
Working file: alloc.c
[snip]
----------------------------
revision 1.2
date: 1999/03/23 12:21:51;  author: lhecking;  state: Exp;  lines: +26 -11
Fix segfault.
=============================================================================

and the git version of ./alloc.c from changeset

36c68278c6b7ee95d3b3eb17f7db2f6243a5ca88
  alloc.c | 35 +++++++++++++++++++++++++----------
  1 file changed, 25 insertions(+), 10 deletions(-)

     Fix segfault.

sebald@ ~/gnuplot/git_translation/reposurgeon/gnuplot-conversion $ diff 
-u ~/gnuplot/gnuplot/gnuplot/alloc.c gnuplot-git/alloc.c
--- /home/sebald/gnuplot/gnuplot/gnuplot/alloc.c    2017-10-27 
11:13:19.527538578 -0500
+++ gnuplot-git/alloc.c    2017-10-27 11:15:23.962994028 -0500
@@ -1,5 +1,5 @@
  #ifndef lint
-static char *RCSid = "$Id: alloc.c,v 1.2 1999/03/23 12:21:51 lhecking 
Exp $";
+static char *RCSid = "$Id: alloc.c,v 1.12 1998/03/22 22:31:16 drd Exp $";
  #endif

  /* GNUPLOT - alloc.c */

That changeset is on master branch and has nothing to do with the 3.7.x 
series at that point in time.  That suggests the master branch is not in 
sync with the CVS repository until just after the massive directory 
restructuring.

Dan

Re: Update on the branch surgery

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

On 10/27/2017 03:09 PM, Hans-Bernhard Bröker wrote:
> Am 27.10.2017 um 10:56 schrieb Daniel J Sebald:
>> On 10/26/2017 08:35 PM, Eric S. Raymond wrote:
> 
>> I've made quite a bit of progress without having to resort to a script 
>> file.  qgit has this nice feature in which one can select a file and 
>> it will list all the changesets that have happened for that particular 
>> file rather than everything changing in the repository. 
> 
> I have my doubts that information about how things _should_ look can 
> meaningfully be gained from looking at the current output of the 
> conversion script.  That information really must be found directly in 
> the _input_, i.e. in the CVS repository.

It's actually pretty good.  The diffs (i.e., changes between versions) 
all seem logical according to the messages.


> Our repository is, as far as I know, almost free of actual defects or 
> corruptions.  The only real hickup is that there's a directory inside an 
> "Attic", which probably shouldn't exist.  CVS itself can still retrieve 
> every tagged version I tried, and the results looked quite sane.

Yes, they look good.  I too have done enough retrieving of files.


> Branch information is right there in the RCS-style archive files, and/or 
> in the "cvs log" of each file (even dropped members), if you know what 
> to look for.  E.g. if you want to know what happened to the instance of 
> version.c that lived directly in the root, you can go to any CVS sandbox 
> and ask for "cvs log version.c", even though "version.c" has long since 
> moved into "src".
> 
>> I've gone back to the CVS repository, no git conversion, and there 
>> simply is no version of alloc.c that has an RCSid of
>>
>> static char *RCSid = "$Id: alloc.c,v 1.11 1997/04/10 02:32:39 drd Exp
> 
> That's the content of this line in the original commit, i.e. it was put 
> in there before the beginning of the CVS repository at SF.  You 
> shouldn't assign it any meaning.

That's where the problem lies and it propagates through the master 
branch up until just after 3.7.x at which point the mass movement of 
files sort of corrected the issue.  We have to put that pre-CVS code in 
sync with the start of the CVS repo.  The master branch is constructed 
from diffs, so slight differences at the start get propagated.


>> That drd RCSid (and a lot of the copyright notices...no wonder they 
>> are going backward from 1999 to 1998) must be coming from prior to the 
>> start of this CVS. 
> 
> FWIW, "drd" is Dave Denholm, who was the maintainer before Lars Hecking, 
> and before we started using SF.net.  And yes, at least Dave, and 
> possibly Lars, too, did run their own CVS behind closed doors.

Do you think there is an old CVS repo from Dave Denholm about somewhere? 
  We don't need it, but it would be interesting if to look at.

Dan

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> >This means that complex join you're talking about is gone.  All
> >branches are now off trunk; the remaining question is where 3.7.x
> >should be rooted, and how many of the commits early on the branch can be
> >dropped when we reroot it.
> 
> OK, thanks, they all should be off of the master branch.  I don't think any
> of the 3.7.x branch need to be dropped, and we might want to revisit the
> shims.
> 
> I've made quite a bit of progress without having to resort to a script file.
> qgit has this nice feature in which one can select a file and it will list
> all the changesets that have happened for that particular file rather than
> everything changing in the repository.  With that I can quickly look at the
> evolution of the version and date listed in the file version.c.  (I don't
> know why I didn't think to look at version.c sooner.)

I did.  It's how I tracked down some of the true branch joins before you guys
did the CVS analysis.

> That drd RCSid (and a lot of the copyright notices...no wonder they are
> going backward from 1999 to 1998) must be coming from prior to the start of
> this CVS.  I'm going to guess that drd, et al. were using a different CVS
> repository prior to the start for which there *was* a version 1.11 of this
> file.  But then Lars started a new one.
> 
> OK, so the current git repository on sourceforge has a problem at the very
> onset that is propagated throughout the whole master branch.  It's that
> issue with the branch point of master we discussed previously.  I'm going to
> need a recent git repository, but I think I've found the 3.7.0 version
> location and I'm pretty sure we'll be in good shape if we get that initial
> series of imports and branches correct.

At leasr part of the problem is this sequence at the beginning:

c57b183 *** empty log message ***   <--- branch point
e2e7fb8 Initial import of beta340.
73285bb Content from historic/gnuplot-3.5.tar.gz
cdd7d69 Content from historic/gnuplot-3.2.tar.gz
6070b01 Content from historic/gnuplot-3.1.tar.gz
605e727 Content from historic/gnuplot-3.0.tar.gz
6bc888c Content from historic/gnuplot-2.0.tar.gz
55fe23a Content from historic/gnuplot-1.10A.tar.gz
e56802d Content from historic/gnuplot-1.1.tar.gz

That top commit is actually an import of 3.6 beta - I'll edit the comment
to reflect that at some point.  Also that beta 340 is a 3.4.0 beta which
should swap places with the 3.5 commit.  3.7. branches off from c57b183.

The real problem, I think, is the early 3.7 commits:

e30004 Rewrite option handling and use execvp() instead of execl().
ad4911d Windows linestyle fix.
cccd8de Import of beta 347.
9a208db Import of beta 346.
0a418be Import of beta 345.
7c5413c Import of beta 344.
78d32b1 Import of beta 343.
00d2bf2 Initial import of beta340.
c57b183 *** empty log message ***   <--- branch point

Internally all of those up to 347 actually predate the 3.6 beta. I think this
is where your weird RCS IDs - and probably other divergences - are coming from.
I'm thinking about making a conversio with those commits (especially the dubious
re-import of 3.4.0) ripped out.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

[Hans-Bernhard B. <HBB...@t-...>]

Am 27.10.2017 um 10:56 schrieb Daniel J Sebald:
> On 10/26/2017 08:35 PM, Eric S. Raymond wrote:

> I've made quite a bit of progress without having to resort to a script 
> file.  qgit has this nice feature in which one can select a file and it 
> will list all the changesets that have happened for that particular file 
> rather than everything changing in the repository.  

I have my doubts that information about how things _should_ look can 
meaningfully be gained from looking at the current output of the 
conversion script.  That information really must be found directly in 
the _input_, i.e. in the CVS repository.

Our repository is, as far as I know, almost free of actual defects or 
corruptions.  The only real hickup is that there's a directory inside an 
"Attic", which probably shouldn't exist.  CVS itself can still retrieve 
every tagged version I tried, and the results looked quite sane.

Branch information is right there in the RCS-style archive files, and/or 
in the "cvs log" of each file (even dropped members), if you know what 
to look for.  E.g. if you want to know what happened to the instance of 
version.c that lived directly in the root, you can go to any CVS sandbox 
and ask for "cvs log version.c", even though "version.c" has long since 
moved into "src".

> I've gone back to the CVS repository, no git conversion, and there 
> simply is no version of alloc.c that has an RCSid of
> 
> static char *RCSid = "$Id: alloc.c,v 1.11 1997/04/10 02:32:39 drd Exp

That's the content of this line in the original commit, i.e. it was put 
in there before the beginning of the CVS repository at SF.  You 
shouldn't assign it any meaning.

> That drd RCSid (and a lot of the copyright notices...no wonder they are 
> going backward from 1999 to 1998) must be coming from prior to the start 
> of this CVS.  

FWIW, "drd" is Dave Denholm, who was the maintainer before Lars Hecking, 
and before we started using SF.net.  And yes, at least Dave, and 
possibly Lars, too, did run their own CVS behind closed doors.

Re: Update on the branch surgery

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

On 10/27/2017 11:50 AM, Daniel J Sebald wrote:
> On 10/27/2017 03:56 AM, Daniel J Sebald wrote:
[snip]
> 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:
> 
> ============================================================================= 
> 
> 
> RCS file: /cvsroot/gnuplot/gnuplot/Attic/alloc.c,v
> Working file: alloc.c
> head: 1.3
> branch:
> locks: strict
> access list:
> symbolic names:
> keyword substitution: kv
> total revisions: 6;    selected revisions: 6
> description:
> ----------------------------
> revision 1.3
> date: 1999/03/26 21:45:50;  author: lhecking;  state: dead;  lines: +1 -1
> Moved to src/.
> ----------------------------
> revision 1.2
> date: 1999/03/23 12:21:51;  author: lhecking;  state: Exp;  lines: +26 -11
> Fix segfault.
> ----------------------------
> revision 1.1
> date: 1998/04/15 19:16:27;  author: lhecking;  state: Exp;
> branches:  1.1.1;
> Initial revision
> ----------------------------
> revision 1.1.1.2
> date: 1998/04/15 19:21:56;  author: lhecking;  state: Exp;  lines: +24 -9
> branches:  1.1.1.2.2;
> Import of beta 343.
> ----------------------------
> revision 1.1.1.1
> date: 1998/04/15 19:16:27;  author: lhecking;  state: Exp;  lines: +0 -0
> Initial import of beta340.
> ----------------------------
> revision 1.1.1.2.2.1
> date: 2001/06/25 16:06:34;  author: broeker;  state: Exp;  lines: +6 -5
> histeps vs. log y axis bugfix, and gp_alloc return type fixed
> ============================================================================= 

Eric,

In the current version of git repository there are the following first 
two changesets:

commit 0a606cafef166159398ad975ad56e4492f80cb82
Author: Lars Hecking <lhe...@nm...>
Date:   Wed Apr 15 20:16:46 1998 +0100

     Initial import of beta340.

commit 073a0e00ba43dd4d0dd78db04b51226c73ca9656
Author: Lars Hecking <lhe...@nm...>
Date:   Wed Apr 15 20:16:47 1998 +0100

     *** empty log message ***

at which point there is a bifurcation into "master" and "3.7.3" branches 
(we know the latter branch has to be grafted somewhere).  I take it that 
the branch at the very start is a result of this sort of thing at the start:

----------------------------
revision 1.1.1.1
date: 1998/04/15 19:16:27;  author: lhecking;  state: Exp;  lines: +0 -0
Initial import of beta340.
----------------------------

Anyway, if I understand correctly, you began with the code base of 
pre-CVS which was this

[1.1][1.10A][2.0][3.0][3.1][3.2][3.5] Initial import of beta340.

i.e., that very first commit in gnuplot-git.  Actually, there are no 
files in that commit.  It is the next commit *** empty log message *** 
where the files come in.  (Shouldn't those files come in with the first 
commit already?)

There is something missing between the import of these pre-CVS files and 
the master branch; it's the "Initial revision":

----------------------------
revision 1.1
date: 1998/04/15 19:16:27;  author: lhecking;  state: Exp;
branches:  1.1.1;
Initial revision
----------------------------

What I mean by that is the CVS repository really starts with something 
different than the imported files as they existed just prior to import. 
By creating the new CVS repository, Lars probably did some picking and 
choosing (intentional or not...noting HBB's explanation of how CVS file 
versioning works and how Lars could have something slightly different on 
his system).  What's more, the very action of Lars creating that Initial 
revision is going to replace all the RCSid strings from DRD's code base 
with the new RCSid strings from Lars' code base.

I think what we need to do as the very second step/changeset is extract 
the CVS repository as it existed just after its creation:

cvs update -D"1998/04/15 19:16:53"

(I picked a time 1 minute after was looked like the time associated with 
the latest "Initial revision" entry in the CVS log...is that correct HBB?)

and then branch the master off of that introduced changeset.  That way 
we are assured that master branch starts with something exactly the same 
as what the Lars CVS repository starts with.

Dan

Re: Update on the branch surgery

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

On 10/27/2017 03:56 AM, Daniel J Sebald wrote:
> OK, so the current git repository on sourceforge has a problem at the 
> very onset that is propagated throughout the whole master branch.  It's 
> that issue with the branch point of master we discussed previously.  I'm 
> going to need a recent git repository, but I think I've found the 3.7.0 
> version location and I'm pretty sure we'll be in good shape if we get 
> that initial series of imports and branches correct.

All right, following up on where I left off, I believe I've found what 
the issue is but don't know how to fix it.  I've created the latest 
gnuplot-git translation from the address here:

On 10/26/2017 08:35 PM, Eric S. Raymond wrote:
 > The picture looks significantly different now. You should get the
 > latest version of the conversion script via
 >
 >         wgethttp://www.catb.org/~esr/gnuplot-conversion.tar.gz
 >
 > Because I know you're trying to save the 3.7.x branch, I have 
rectified the
 > 4-0-stable branch - I rerooted it to where it should have branched off
 > master in 2004 and inserted a shim commit to make demo/gnuplot.rot right
 > at the branch tip.

I now see the branches all coming from the trunk.  However, the probably 
I described last night is still present.  It explains all the 
discrepancy I've been seeing, and it also explains the shim Eric needed 
to apply to resolve this difference:

# HBB: revised open-ended animation routine. Used to just turn
# round and round by somewhat large steps. Now, it tumbles
# back and forth smoothly.
# If 'limit_iterations' is set to a nonzero value, it'll stop after that
# many iterations (iteration_count=0 has to be set before this
# script is called)
zrot=(zrot+10)%360
xrot=(xrot+17)%180

I was seeing similar types of discrepancies in the demo files in the CVS 
GNUPLOT_RELEASE_3_7_0 versus git "Windows linestyle fix" comparison.

Similar to what I described last night, the latest git translation still 
has the not-quite-correct master branch from the very beginning.  The 
translation conflates the DRD pre-CVS repository versions of files. 
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.

To illustrate how at the very beginning of the repository the master 
branch goes askew, here is a comparison of CVS

=============================================================================
RCS file: /cvsroot/gnuplot/gnuplot/Attic/alloc.c,v
Working file: alloc.c
[snip]
----------------------------
revision 1.2
date: 1999/03/23 12:21:51;  author: lhecking;  state: Exp;  lines: +26 -11
Fix segfault.
=============================================================================

and the git version of ./alloc.c from changeset

36c68278c6b7ee95d3b3eb17f7db2f6243a5ca88
  alloc.c | 35 +++++++++++++++++++++++++----------
  1 file changed, 25 insertions(+), 10 deletions(-)


sebald@ ~/gnuplot/git_translation/reposurgeon/gnuplot-conversion $ diff 
-u ~/gnuplot/gnuplot/gnuplot/alloc.c gnuplot-git/alloc.c
--- /home/sebald/gnuplot/gnuplot/gnuplot/alloc.c	2017-10-27 
11:13:19.527538578 -0500
+++ gnuplot-git/alloc.c	2017-10-27 11:15:23.962994028 -0500
@@ -1,5 +1,5 @@
  #ifndef lint
-static char *RCSid = "$Id: alloc.c,v 1.2 1999/03/23 12:21:51 lhecking 
Exp $";
+static char *RCSid = "$Id: alloc.c,v 1.12 1998/03/22 22:31:16 drd Exp $";
  #endif

  /* GNUPLOT - alloc.c */

OK, the above difference, for a hundred-plus files is what I'm seeing 
when attempting to graft the "Windows linestyle fix." onto master branch.

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:

=============================================================================

RCS file: /cvsroot/gnuplot/gnuplot/Attic/alloc.c,v
Working file: alloc.c
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 6;	selected revisions: 6
description:
----------------------------
revision 1.3
date: 1999/03/26 21:45:50;  author: lhecking;  state: dead;  lines: +1 -1
Moved to src/.
----------------------------
revision 1.2
date: 1999/03/23 12:21:51;  author: lhecking;  state: Exp;  lines: +26 -11
Fix segfault.
----------------------------
revision 1.1
date: 1998/04/15 19:16:27;  author: lhecking;  state: Exp;
branches:  1.1.1;
Initial revision
----------------------------
revision 1.1.1.2
date: 1998/04/15 19:21:56;  author: lhecking;  state: Exp;  lines: +24 -9
branches:  1.1.1.2.2;
Import of beta 343.
----------------------------
revision 1.1.1.1
date: 1998/04/15 19:16:27;  author: lhecking;  state: Exp;  lines: +0 -0
Initial import of beta340.
----------------------------
revision 1.1.1.2.2.1
date: 2001/06/25 16:06:34;  author: broeker;  state: Exp;  lines: +6 -5
histeps vs. log y axis bugfix, and gp_alloc return type fixed
=============================================================================

How should we proceed Eric?

Dan

Re: Re: Re: Re: News spin of repository conversion

[Eric S. R. <es...@th...>]

"Bastian Märkisch" <bma...@we...>:
> 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

Crap.

Can you find and send me a pair of ChangeLogs that exhibits this kind of change?
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

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

On 10/26/2017 08:35 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> OK, now the two things I feel are unresolved.
>>
>> 1) We need to figure out where CVS GNUPLOT_RELEASE_3_7_0 corresponds to the
>> git master branch changeset, and create a tag 3.7.0 for that.  That will
>> also be the grafting point for the 3.7.x series branch.
> 
> Agreed, if we're foing to save that branch at all/
> 
>> 2) The master branch point in the attached screenshot of qgit originates
>> from before beta340, beta343, etc.  I wonder if master branch should instead
>> start at the point where all the other branches in that screenshot are
>> emanating.  The point prior to import of beta340, etc. would be "Initial
>> revision".
> 
> The picture looks significantly different now. You should get the
> latest version of the conversion script via
> 
>         wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz
> 
> Because I know you're trying to save the 3.7.x branch, I have rectified the
> 4-0-stable branch - I rerooted it to where it should have branched off
> master in 2004 and inserted a shim commit to make demo/gnuplot.rot right
> at the branch tip.
> 
> This means that complex join you're talking about is gone.  All
> branches are now off trunk; the remaining question is where 3.7.x
> should be rooted, and how many of the commits early on the branch can be
> dropped when we reroot it.

OK, thanks, they all should be off of the master branch.  I don't think 
any of the 3.7.x branch need to be dropped, and we might want to revisit 
the shims.

I've made quite a bit of progress without having to resort to a script 
file.  qgit has this nice feature in which one can select a file and it 
will list all the changesets that have happened for that particular file 
rather than everything changing in the repository.  With that I can 
quickly look at the evolution of the version and date listed in the file 
version.c.  (I don't know why I didn't think to look at version.c sooner.)

At the first changeset, "Windows linestyle fix.", of that 3.7.x branch 
the contents of version.c are:

char version[] = "3.7";
char patchlevel[] = "0";
char date[] = "Thu Jan 14 19:34:53 BST 1999";
char gnuplot_copyright[] = "Copyright(C) 1986 - 1993, 1998, 1999";

Looking through the evolution of version.c on the trunk, the above 
information corresponds to the range

New date string.          1/14/99 1:35 PM
char version[] = "3.7";
char patchlevel[] = "0";
char date[] = "Thu Jan 14 19:34:53 BST 1999";

New patchlevel.           1/26/99 7:49 AM
char version[] = "3.7";
char patchlevel[] = "1";
char date[] = "Thu Jan 14 19:34:53 BST 1999";

The first version above is the first appearance of that particular 
date[].  The next version varies in the patch level (i.e., different 
from the "Windows linestyle fix." version.  That's about a dozen 
checkins or so, which I can do manually.  So here it goes...

[1/14/99 8:13 AM] Child: Windows linestyle fix.
git -C branch_reference checkout 3f354a490c5839042db43ca0bdc30a87ec54882c
---
commit 4246b753d7c88b71131db21013e1d083df03a41b
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Tue Jan 26 13:42:30 1999 +0000
     Add R.Fearicks PGP key.
git -C root_reference checkout 4246b753d7c88b71131db21013e1d083df03a41b
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
756 + 1001
---
commit 3b532520520eb44172b2035ed612031489ca17f1
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Tue Jan 26 13:42:18 1999 +0000
     Add contents of new lisp subdir.
git -C root_reference checkout 3b532520520eb44172b2035ed612031489ca17f1
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
739 + 1001
---
commit 69e824692b443cd978b7c030979183345b30b874
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Tue Jan 26 13:39:18 1999 +0000
     Take out part about dartmouth ftpmail.
git -C root_reference checkout 69e824692b443cd978b7c030979183345b30b874
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
722 + 997
---
commit 3f931c64ee321f083e199ba02950cdc9019f99cd
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Thu Jan 14 19:35:52 1999 +0000
     New file.
git -C root_reference checkout 3f931c64ee321f083e199ba02950cdc9019f99cd
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
722 + 977
---
commit cc12bfe09ac8fc58aaf14a839d6f0c88b881d80d
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Thu Jan 14 19:35:25 1999 +0000
     New date string.
git -C root_reference checkout cc12bfe09ac8fc58aaf14a839d6f0c88b881d80d
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
722 + 977
---
commit 6c5bae9e97d91bb3f1feefaa420cca5e081a8d72
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Thu Jan 14 19:34:40 1999 +0000
     Add copyright note.
git -C root_reference checkout 6c5bae9e97d91bb3f1feefaa420cca5e081a8d72
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
723 + 978
---
commit 7e6c32e2525e903d41c9f2dfdb538ec874221f89
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Thu Jan 14 19:34:16 1999 +0000
     Add PGPKEYS.
git -C root_reference checkout 7e6c32e2525e903d41c9f2dfdb538ec874221f89
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
723 + 982
---
commit ec0e9cd9964cff216a3cc4d9e82ece2a34f83173
Author: Laxx Hexxxxx <xxxxxx@xxxxxx>
Date:   Thu Jan 14 19:33:43 1999 +0000
     Updated.
git -C root_reference checkout ec0e9cd9964cff216a3cc4d9e82ece2a34f83173
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^-"| 
grep -v "^---" | wc -l
diff -ur --exclude=".git" root_reference/ branch_reference/ | grep "^+"| 
grep -v "^+++" | wc -l
749 + 1008


So, it boils down to these two:

commit 3f931c64ee321f083e199ba02950cdc9019f99cd
Date:   Thu Jan 14 19:35:52 1999 +0000
     New file.
722 + 977
---
commit cc12bfe09ac8fc58aaf14a839d6f0c88b881d80d
Date:   Thu Jan 14 19:35:25 1999 +0000
722 + 977

OK, I'm looking at the diffs for these two (very similar of course). 
There is too much code changes (as opposed to documentation and version 
change) for these to be the branch point for "Windows linestyle fix.". 
But, I think something is odd about the diffs I'm seeing right now, so 
I'll skip this idea for now and come back to it.

So, let's just answer the GNUPLOT_RELEASE_3_7_0 question.  Consider the 
following from CVS log:

PGPKEYS:
	GNUPLOT_RELEASE_3_7_0: 1.1

OK, so 3f931c64ee321f083e199ba02950cdc9019f99cd must be in 3.7.0.

OREADME:
	GNUPLOT_RELEASE_3_7_0: 1.10
----------------------------
revision 1.11
date: 1999/01/26 13:39:18;  author: lhecking;  state: Exp;  lines: +0 -20
Take out part about dartmouth ftpmail.
----------------------------
revision 1.10
date: 1999/01/13 21:48:26;  author: lhecking;  state: Exp;  lines: +1 -1
branches:  1.10.2;
Add Win9[58] to platform list.
----------------------------

Well, that means revision 1.11 and hence
commit 69e824692b443cd978b7c030979183345b30b874
Date:   Tue Jan 26 13:39:18 1999 +0000
     Take out part about dartmouth ftpmail.

(the checkin after 3f931c64) is *not* in 3.7.0.

Hence, my best guess for version 3.7.0 is

commit 3f931c64ee321f083e199ba02950cdc9019f99cd
Date:   Thu Jan 14 19:35:52 1999 +0000
     New file.


OK, so as with 3.7.1, et al., I do a diff with CVS GNUPLOT_RELEASE_3_7_0 
and that particular changeset, and once again I see all these RCSid 
differences.  There are a lot of copyright differences, and there are 
some demo and doc directory file differences, one or two similar to that 
HBB.

Something's odd.  Here's an example of the RCSid difference:

diff -ur '--exclude=.git' root_reference/alloc.c gnuplot/alloc.c
--- root_reference/alloc.c	2017-10-26 23:54:21.297038908 -0500
+++ gnuplot/alloc.c	1998-04-15 14:21:56.000000000 -0500
@@ -1,11 +1,11 @@
  #ifndef lint
-static char *RCSid = "$Id: alloc.c,v 1.11 1997/04/10 02:32:39 drd Exp $";
+static char *RCSid = "$Id: alloc.c,v 1.1.1.2 1998/04/15 19:21:56 
lhecking Exp $";
  #endif

I've gone back to the CVS repository, no git conversion, and there 
simply is no version of alloc.c that has an RCSid of

static char *RCSid = "$Id: alloc.c,v 1.11 1997/04/10 02:32:39 drd Exp

There is no 1.11 for ./alloc.c, and I've looked at everyone of the 
versions of alloc.c in the CVS repository and there's no drd anywhere 
for that file.

sebald@ ~/gnuplot/gnuplot/gnuplot $ cvs diff -u -r1.1 -r1.1.1.1 alloc.c
Index: alloc.c
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/Attic/alloc.c,v
retrieving revision 1.1
retrieving revision 1.1.1.1
diff -u -r1.1 -r1.1.1.1
--- alloc.c	15 Apr 1998 19:16:27 -0000	1.1
+++ alloc.c	15 Apr 1998 19:16:27 -0000	1.1.1.1
@@ -1,5 +1,5 @@
  #ifndef lint
-static char *RCSid = "$Id: alloc.c,v 1.1 1998/04/15 19:16:27 lhecking 
Exp $";
+static char *RCSid = "$Id: alloc.c,v 1.1.1.1 1998/04/15 19:16:27 
lhecking Exp $";
  #endif


That drd RCSid (and a lot of the copyright notices...no wonder they are 
going backward from 1999 to 1998) must be coming from prior to the start 
of this CVS.  I'm going to guess that drd, et al. were using a different 
CVS repository prior to the start for which there *was* a version 1.11 
of this file.  But then Lars started a new one.

OK, so the current git repository on sourceforge has a problem at the 
very onset that is propagated throughout the whole master branch.  It's 
that issue with the branch point of master we discussed previously.  I'm 
going to need a recent git repository, but I think I've found the 3.7.0 
version location and I'm pretty sure we'll be in good shape if we get 
that initial series of imports and branches correct.

Dan

Aw: Re: Re: Re: News spin of repository conversion

[Bastian M. <bma...@we...>]

> Daniel J Sebald <dan...@ie...>:
> > I've enhanced my utility with the following subtle change:  search for first
> > item (i.e., line has a star * or colon :) within the addition diff hunk.
> > This corrected 4 entries, which I've listed on SourceForge here:
> > 
> > https://sourceforge.net/p/gnuplot/patches/763/#5709
> 
> My code picks up all four of these cases.
> 
> I believe the ChangeLog-parsing algorithm parsing is now good enough.

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

  Bastian

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> OK, now the two things I feel are unresolved.
> 
> 1) We need to figure out where CVS GNUPLOT_RELEASE_3_7_0 corresponds to the
> git master branch changeset, and create a tag 3.7.0 for that.  That will
> also be the grafting point for the 3.7.x series branch.

Agreed, if we're foing to save that branch at all/

> 2) The master branch point in the attached screenshot of qgit originates
> from before beta340, beta343, etc.  I wonder if master branch should instead
> start at the point where all the other branches in that screenshot are
> emanating.  The point prior to import of beta340, etc. would be "Initial
> revision".

The picture looks significantly different now. You should get the
latest version of the conversion script via

       wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz

Because I know you're trying to save the 3.7.x branch, I have rectified the
4-0-stable branch - I rerooted it to where it should have branched off
master in 2004 and inserted a shim commit to make demo/gnuplot.rot right
at the branch tip.

This means that complex join you're talking about is gone.  All
branches are now off trunk; the remaining question is where 3.7.x
should be rooted, and how many of the commits early on the branch can be
dropped when we reroot it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

Daniel J Sebald <dan...@ie...>:
> >Huh.
> >On the one hand, that makes sense.
> >On the other hand there must also be a CVS check-in date for that change.
> >Why would you trust the text field in the ChangeLog more than the
> >check-in date?
> 
> We do trust the check-in date; that becomes the commit timestamp in the git
> repository. What we are trying to reconstruct is the correct Author and
> author timestamp.

Daniel is correct. Picking up this bad date is an artifact of ChangeLog mining.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

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

On 10/25/2017 10:16 PM, Eric S. Raymond wrote:
> Ethan A Merritt <sf...@us...>:
>> On Wednesday, October 25, 2017 3:18:37 PM PDT Eric S. Raymond wrote:
>>> I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
>>> it on /#include gp_time.h/ yields this diff at the tip:
>>>
>>> --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
>>> +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
>>> @@ -1,12 +1,5 @@
>>> -# HBB: revised open-ended animation routine. Used to just turn
>>> -# round and round by somewhat large steps. Now, it tumbles
>>> -# back and forth smoothly.
>>> -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
>>> -# many iterations (iteration_count=0 has to be set before this -#
>>> script is called)
>>>   zrot=(zrot+10)%360
>>>   xrot=(xrot+17)%180
>>> -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
>>> +set view xrot,zrot
>>>   replot
>>> -iteration_count=iteration_count+1
>>> -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
>>> +reread
>>
>> That file has only been touched twice, once in 1998 and once in 2006.
>> The diff you list above was the 1998 change.
> 
> Hm. That's not what I see.
> 
> reposurgeon% [demo/gnuplot.rot] list
>    1009 1998-04-15T19:16:47Z  :1008 *** empty log message ***
>    1370 1998-04-22T13:40:59Z  :1369 Import of beta 344.
>   18500 2005-01-07T23:21:02Z :18499 Revise gif animation code to comply with

As Ethan mentioned, there may have been a typo in the ChangeLog 
time/date.  But that should be author info, not commit info.


>> At a guess, the 07-Jan-2006 change is right at the time of the 4.2 branch
>> and got caught on the wrong side of it.
> 
> Alas, it's nastier than that. The import of 344 is a commit that was only
> on the bizarro-branch leading to 3.7.1.  The 4-0-stable branch was rooted
> in *that import*, not the trunk leading 4 4 and everything later.
> 
> Here is what the repo structure looks like now, with the 5.0/4.6/4.4/4.2
> grafts done:
> 
> ------+--------+---------+-------+----------+---------+-------- master
>        |        |         |       |          |         |
>        |        |         |       |          |         +----- 5-2-stable
>        |        |         |       |          |
>        |        |         |       |          +------------ 5-0 stable
>        |        |         |       |
>        |        |         |       +-------------------- 4-6-stable
>        |        |         |
>        |        |         +------------------------- 4-4-stable
>        |        |
>        |        +-------------------------------- 4.2-stable
>        |
>        +--------X---------- 3.7.1
>                 |
> 	       +------------------ 4.0-stable
> 
> X marks the spot where the shortened version of the demo visible at the
> 4-0-stable tip (before surgery) was introduced.  When 4.0 is rerooted
> to the logical spot on the master branch, the longer 1998 version is exposed.

I'm not following completely, but I'll come to understand this as I look 
at the CVS/git comparison a bit more.  Certainly branch-4-0-stable 
should come from the trunk.  I looked at all the CVS time stamps and the 
versions are all 1.x associated with GNUPLOT_RELEASE_4_0_0, except for 
those in the /demo and /doc directories which have 1.1.1.x.  In 
contrast, the GNUPLOT_RELEASE_3_7_1 variety of tag has all sorts of 
1.3.x, 1.1.2.x sorts of versions for the main source files.

So, the 3.7.0 and 4.0.0 tag positions are in question.  I'll investigate 
by writing a script file to do repository directory-vs-directory 
comparison.  But that will take a little bit of time because I'm not 
fluent with writing script syntax conditionals, looping, number addition 
(to count and compare line difference, min-tests, etc.).

Dan

Re: Update on the branch surgery

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

On 10/26/2017 12:39 PM, Ethan A Merritt wrote:
> On Thursday, October 26, 2017 9:50:20 AM PDT Daniel J Sebald wrote:
> 
>>> The incorrect date comes from a typo in the ChangeLog.
>>>
>>>     https://sourceforge.net/p/gnuplot/git-main/ci/50bc9c8abfd499a56717cc
>>>     f324434bdc675e2bea/>
>>> Note, however, that typo is not present in the main branch copy of
>>> ChangeLog (actually ChangeLog.1) because it was later corrected.  That
>>> leads me to wonder which era of the ChangeLog text you guys are mining
>>> to assign dates during the git conversion.
>>
>> We aren't using any changelog file.  What we are looking at is the
>> *changes* to ChangeLog as they are associated with the changes in other
>> files.  That is, every time something was checked into CVS there was
>> always a small change to the ChangeLog file as well.  That trail
>> contains the most information.  So, if there was a typo in the ChangeLog
>> entry for a particular checkin, that mistaken date ends up in the git
>> changeset.
>>
>> It's not possible to look at a whole ChangeLog file and infer dates and
>> times about myriad checkins because that ChangeLog was constructed in a
>> piecemeal fashion, placing an item under some entry days prior, editing
>> some past entry, placing a new entry before other entries rather than
>> the top of the file, etc.
>>
>> The typo explains the date discrepancy (thanks).  There's going to be a
>> few of those.  After the fact we can attempt a simple rebase/correct and
>> if it works, fine, if not just live with those sorts of issues.  That's
>> the minor concern aside from getting the graft points correct.
>>
>> Dan
> 
> Huh.
> On the one hand, that makes sense.
> On the other hand there must also be a CVS check-in date for that change.
> Why would you trust the text field in the ChangeLog more than the
> check-in date?

We do trust the check-in date; that becomes the commit timestamp in the 
git repository.  What we are trying to reconstruct is the correct Author 
and author timestamp.  That's why in qgit, etc. the changeset is in the 
correct order, but the author date jumps around a bit (e.g., five days 
prior, one day prior, etc.).

The way it will work with git is that non-maintainer developers will 
create changesets locally for bug fixes.  Then they'll export that 
changeset and post to the bug tracker.  In that ASCII file will be the 
Author and author date/time information.  When the maintainers accept 
that change, they'll commit the changeset (perhaps with some minor 
tweaks to commit message and code), then push to the canonical 
repository.  The maintainer's info will be listed in Committer, while 
the original author will be listed in Author.  Mercurial has the same 
approach, see for example

http://hg.savannah.gnu.org/hgweb/octave/

where the author dates can be months behind the commit dates.

This will save maintainer's time because the responsibility of the FSF 
"ChangeLog" message will now fall upon the original author, for the most 
part, and no more ChangeLog to maintain.

Dan

Re: Update on the branch surgery

[Ethan A M. <sf...@us...>]

On Thursday, October 26, 2017 9:50:20 AM PDT Daniel J Sebald wrote:

> > The incorrect date comes from a typo in the ChangeLog.
> > 
> >    https://sourceforge.net/p/gnuplot/git-main/ci/50bc9c8abfd499a56717cc
> >    f324434bdc675e2bea/> 
> > Note, however, that typo is not present in the main branch copy of
> > ChangeLog (actually ChangeLog.1) because it was later corrected.  That
> > leads me to wonder which era of the ChangeLog text you guys are mining
> > to assign dates during the git conversion.
> 
> We aren't using any changelog file.  What we are looking at is the
> *changes* to ChangeLog as they are associated with the changes in other
> files.  That is, every time something was checked into CVS there was
> always a small change to the ChangeLog file as well.  That trail
> contains the most information.  So, if there was a typo in the ChangeLog
> entry for a particular checkin, that mistaken date ends up in the git
> changeset.
> 
> It's not possible to look at a whole ChangeLog file and infer dates and
> times about myriad checkins because that ChangeLog was constructed in a
> piecemeal fashion, placing an item under some entry days prior, editing
> some past entry, placing a new entry before other entries rather than
> the top of the file, etc.
> 
> The typo explains the date discrepancy (thanks).  There's going to be a
> few of those.  After the fact we can attempt a simple rebase/correct and
> if it works, fine, if not just live with those sorts of issues.  That's
> the minor concern aside from getting the graft points correct.
> 
> Dan

Huh.
On the one hand, that makes sense.
On the other hand there must also be a CVS check-in date for that change.
Why would you trust the text field in the ChangeLog more than the
check-in date?

	(sorry if you've already gone over this in previous mail,
	 I have not tried to follow the detailed discussion)

		Ethan

Re: Update on the branch surgery

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

On 10/26/2017 11:31 AM, sfeam wrote:
> On Wednesday, 25 October 2017 23:16:15 Eric S. Raymond wrote:
>> Ethan A Merritt <sf...@us...>:
>>> On Wednesday, October 25, 2017 3:18:37 PM PDT Eric S. Raymond wrote:
>>>> I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
>>>> it on /#include gp_time.h/ yields this diff at the tip:
>>>>
>>>> --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
>>>> +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
>>>> @@ -1,12 +1,5 @@
>>>> -# HBB: revised open-ended animation routine. Used to just turn
>>>> -# round and round by somewhat large steps. Now, it tumbles
>>>> -# back and forth smoothly.
>>>> -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
>>>> -# many iterations (iteration_count=0 has to be set before this -#
>>>> script is called)
>>>>   zrot=(zrot+10)%360
>>>>   xrot=(xrot+17)%180
>>>> -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
>>>> +set view xrot,zrot
>>>>   replot
>>>> -iteration_count=iteration_count+1
>>>> -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
>>>> +reread
>>>
>>> That file has only been touched twice, once in 1998 and once in 2006.
>>> The diff you list above was the 1998 change.
>>
>> Hm. That's not what I see.
>>
>> reposurgeon% [demo/gnuplot.rot] list
>>    1009 1998-04-15T19:16:47Z  :1008 *** empty log message ***
>>    1370 1998-04-22T13:40:59Z  :1369 Import of beta 344.
>>   18500 2005-01-07T23:21:02Z :18499 Revise gif animation code to comply with
>>
>> That first one looks like the initial import.  Two following changes, all
>> right, first in 1998, but the second early in 2005 rather than in 2006.
> 
> The incorrect date comes from a typo in the ChangeLog.
>    https://sourceforge.net/p/gnuplot/git-main/ci/50bc9c8abfd499a56717ccf324434bdc675e2bea/
> 
> Note, however, that typo is not present in the main branch copy of ChangeLog
> (actually ChangeLog.1) because it was later corrected.  That leads me to wonder
> which era of the ChangeLog text you guys are mining to assign dates during the
> git conversion.

We aren't using any changelog file.  What we are looking at is the 
*changes* to ChangeLog as they are associated with the changes in other 
files.  That is, every time something was checked into CVS there was 
always a small change to the ChangeLog file as well.  That trail 
contains the most information.  So, if there was a typo in the ChangeLog 
entry for a particular checkin, that mistaken date ends up in the git 
changeset.

It's not possible to look at a whole ChangeLog file and infer dates and 
times about myriad checkins because that ChangeLog was constructed in a 
piecemeal fashion, placing an item under some entry days prior, editing 
some past entry, placing a new entry before other entries rather than 
the top of the file, etc.

The typo explains the date discrepancy (thanks).  There's going to be a 
few of those.  After the fact we can attempt a simple rebase/correct and 
if it works, fine, if not just live with those sorts of issues.  That's 
the minor concern aside from getting the graft points correct.

Dan

Re: Update on the branch surgery

[Eric S. R. <es...@th...>]

sfeam <sf...@us...>:
> The incorrect date comes from a typo in the ChangeLog.
>   https://sourceforge.net/p/gnuplot/git-main/ci/50bc9c8abfd499a56717ccf324434bdc675e2bea/
> 
> Note, however, that typo is not present in the main branch copy of ChangeLog
> (actually ChangeLog.1) because it was later corrected.  That leads me to wonder
> which era of the ChangeLog text you guys are mining to assign dates during the
> git conversion.

For any given changeset, the only ChangeLog mined for attribution is the one
(if any) found in that particular changeset.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.

Re: Update on the branch surgery

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

On Wednesday, 25 October 2017 23:16:15 Eric S. Raymond wrote:
> Ethan A Merritt <sf...@us...>:
> > On Wednesday, October 25, 2017 3:18:37 PM PDT Eric S. Raymond wrote:
> > > I have successfully transplanted 4.2, but 4.0 has a problem.  Rebasing
> > > it on /#include gp_time.h/ yields this diff at the tip:
> > > 
> > > --- a/demo/gnuplot.rot	1998-04-22 09:38:42.000000000 -0400
> > > +++ b/demo/gnuplot.rot	2017-10-25 17:39:55.083147765 -0400
> > > @@ -1,12 +1,5 @@
> > > -# HBB: revised open-ended animation routine. Used to just turn
> > > -# round and round by somewhat large steps. Now, it tumbles
> > > -# back and forth smoothly.
> > > -# If 'limit_iterations' is set to a nonzero value, it'll stop after that
> > > -# many iterations (iteration_count=0 has to be set before this -#
> > > script is called)
> > >  zrot=(zrot+10)%360
> > >  xrot=(xrot+17)%180
> > > -set view (50.+30.*sin(xrot/180.*pi)),60.+45.*sin(zrot/180.*pi)
> > > +set view xrot,zrot
> > >  replot
> > > -iteration_count=iteration_count+1
> > > -if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
> > > +reread
> > 
> > That file has only been touched twice, once in 1998 and once in 2006.
> > The diff you list above was the 1998 change.
> 
> Hm. That's not what I see.
> 
> reposurgeon% [demo/gnuplot.rot] list
>   1009 1998-04-15T19:16:47Z  :1008 *** empty log message ***
>   1370 1998-04-22T13:40:59Z  :1369 Import of beta 344.
>  18500 2005-01-07T23:21:02Z :18499 Revise gif animation code to comply with
> 
> That first one looks like the initial import.  Two following changes, all
> right, first in 1998, but the second early in 2005 rather than in 2006.

The incorrect date comes from a typo in the ChangeLog.
  https://sourceforge.net/p/gnuplot/git-main/ci/50bc9c8abfd499a56717ccf324434bdc675e2bea/

Note, however, that typo is not present in the main branch copy of ChangeLog
(actually ChangeLog.1) because it was later corrected.  That leads me to wonder
which era of the ChangeLog text you guys are mining to assign dates during the
git conversion.

	Ethan

Re: Update on the branch surgery

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

On 10/25/2017 11:36 PM, sfeam via gnuplot-beta wrote:
> On Thursday, 26 October 2017 00:06:43 Eric S. Raymond wrote:
>> The alternatives remain as follows:
>>
>> If it were my call, I'd cut our losses - just drop the 3.7.x and 4.0
>> branches entirely.  That would leave the repo in a very clean state where
>> we have confidence that what is there matches its actual development
>> history quite closely.
> 
> OK by me.

I think the 3.7/4.0 branch stuff is fine, and I think I have a pretty 
good guess at the historical process of releases.  There are a couple 
issues that need resolving (the 3.7.0 tag and the master branch at the 
start), but I'll come back to that.  And I have a suggestion for easily 
rectifying near the end.

As I had done with git-translate changeset "Windows linestyle fix." and 
CVS GNUPLOT_RELEASE_3_7_0, I've done a directory-by-directory comparison 
of git-translate tag 3.7.1 and CVS GNUPLOT_RELEASE_3_7_1.  I've found 
the code to very close, so much so that I trust the changeset history on 
that 3.7.x branch.  I.e.,

cd gnuplot
cvs update -rGNUPLOT_RELEASE_3_7_1
cd ..
git -C branch_reference checkout 77be49b3e61284eb0e3d9d74064c207390cc5565
diff -ur --exclude=".git" branch_reference/ gnuplot/ > 
GNUPLOT_RELEASE_3_7_1_vs_gtag_3.7.1.diff

The diff file is big, so I'm going to email it to just a few folks.  But 
I'll pull out the useful information for explaining what I think was done.

1) The bulk of the diffs between the CVS and git 3.7.1 are of the 
following category:

diff -ur '--exclude=.git' branch_reference/alloc.c gnuplot/alloc.c
--- branch_reference/alloc.c	2017-10-25 16:05:19.146473811 -0500
+++ gnuplot/alloc.c	2017-10-26 00:18:13.471555544 -0500
@@ -1,5 +1,5 @@
  #ifndef lint
-static char *RCSid = "$Id: alloc.c,v 1.12 1998/03/22 22:31:16 drd Exp $";
+static char *RCSid = "$Id: alloc.c,v 1.1.1.2 1998/04/15 19:21:56 
lhecking Exp $";
  #endif

  /* GNUPLOT - alloc.c */

I'm not too worried about the mismatch, but HBB might have an 
explanation as to why the 1.1.1.2.  I think it might be due to branching 
in order to create a little stub for the purpose of a release candidate 
and tarball.  More later.

2) Here is a list of the files that exist in one directory and not the 
other:

sebald@ ~/gnuplot/git_translation/branch_point_search $ grep -i "only 
in" GNUPLOT_RELEASE_3_7_1_vs_gtag_3.7.1.diff

Only in gnuplot/: config
Only in gnuplot/: CVS
Only in gnuplot/demo: CVS
Only in gnuplot/demo: games
Only in gnuplot/demo: html
Only in gnuplot/demo: plugin
Only in gnuplot/docs: CVS
Only in branch_reference/docs: latextut
Only in gnuplot/docs/old: CVS
Only in gnuplot/docs/psdoc: CVS
Only in gnuplot/docs: windows
Only in branch_reference/: .gitignore
Only in gnuplot/m4: CVS
Only in gnuplot/: man
Only in branch_reference/: NeXT
Only in branch_reference/: os2
Only in gnuplot/: pm3d
Only in gnuplot/: share
Only in gnuplot/: src
Only in gnuplot/term: CVS
Only in gnuplot/term: js
Only in gnuplot/term: lua
Only in gnuplot/term: PostScript
Only in gnuplot/: tutorial
Only in gnuplot/win: CVS

Most of the above look like empty directories of CVS.  We don't care 
about those not being in the git repository because there is no code 
loss associated with that.  On the other hand, the directories in git 
repository 3.7.1 *do* contain something:

sebald@ ~/gnuplot/git_translation/branch_point_search $ ls 
branch_reference/docs/latextut/
eg1.plt  eg3.dat  eg4.plt  eg6.plt     linepoin.plt  Makefile.in
eg2.plt  eg3.plt  eg5.plt  header.tex  makefile.dst  tutorial.tex

sebald@ ~/gnuplot/git_translation/branch_point_search $ ls 
branch_reference/NeXT/
bigger.tiff         GnuTerm_main.m       GnuView.m           PB.project
Controller.h        GnuTerm.tiff         Makefile            README.rtf
Controller.m        gnuviewController.h  Makefile.postamble  smaller.tiff
English.lproj       gnuviewController.m  Makefile.preamble
GnuTerm.iconheader  GnuView.h            PB.gdbinit

sebald@ ~/gnuplot/git_translation/branch_point_search $ ls 
branch_reference/os2
dialogs.c  gclient.c    gnupmdrv.c    gnupmdrv.h    gnupmdrv.rc
dialogs.h  gnuplot.ico  gnupmdrv.def  gnupmdrv.ipf  print.c

Those are all files that are missing from the CVS (tarball) version.  My 
suspicion is that at the time whoever created the release/tarball 
figured there was no point in including these files so discarded them 
(on a stub branch).

3) Now, the difference in code between these two versions:  I'm going to 
attach those as short file.  All the changes are related to version 
numbers and dates, except this one:

--- branch_reference/term/tgif.trm	2017-10-25 16:05:19.310473813 -0500
+++ gnuplot/term/tgif.trm	2017-10-26 00:18:18.307555592 -0500
[snip]
state(%d,30,%u,0,0,%u,16,1,9,1,1,0,0,0,0,1,0,'%s',0,%u,0,0,1,10,0,0,1,1,0,16,0,0,1,1,1).\n\
-%%\n%% @(#)$Header: 
/export/home/cheetah/ddenholm/cvsroot/gnuplot/term/tgif.trm,v 1.66 
1998/04/14 00:18:10 drd Exp $\n%% %%W%%\n%%\n\
+%%\n%% @(#)$Header: /cvsroot/gnuplot/gnuplot/term/tgif.trm,v 1.10 
1998/12/16 19:48:20 lhecking Exp $\n%% %%W%%\n%%\n\

I suppose Lars recognized this computer-specific reference at the last 
minute and changed it.  Could it also be that because Lars pulled the 
CVS code onto his machine that the "$Id:" references were changed from 
drd (ddenholm) to lhecking?

My theory on the difference between CVS version GNUPLOT_RELEASE_3_7_1 
and version git tag 3.7.1 is that the current git tag 3.7.1 is not the 
actual "release" that created the tarball.  It's just prior to the 
release, and Lars created a branch off the 3.7.x series at what would be 
tag 3.7.1 that was probably one checkin long, i.e., a short stub the 
purpose of which was to update version/date, clean up various things and 
toss away files from the release that wouldn't be used by anyone (i.e., 
tutorial manual, NeXT, os2).

In other words, the release is just a short little stub off of the 3.7.x 
branch.  Perhaps reposurgeon can't resolve a one-checkin branch (i.e, 
stub).  It may be that all the 3.7.x releases and perhaps the 4.0.0 
release were done this way.  (It wouldn't surprise me that 4.0.0 was 
released from the 3.7.x series and then some kind of merging of all mods 
into master branch.)

Anyway, technically the git tag 3.7.1 is not the actual release.  Here's 
how I propose to resolve this.  After the repository is translated, 
Ethan can, as a first item of action in git,

1) Checkout git tag 3.7.1 and create a branch
2) In some other directory checkout out cvs GNUPLOT_RELEASE_3_7_1
3) Clean the files out of the git directory tree and replace them with 
the files from the cvs directory.
4) Create a git commit from those changes.  (Something like qgit will 
highlight the files that are added, that are missing, and that have 
changed, and Ethan can click the little boxes to stage them into the 
commit.)
5) Remove the git 3.7.1 tag from the branch point and create a new 3.7.1 
tag at the changeset just committed.

So, it's effectively recreating history and we'll have a the 
code/version we want.  We'll do that with the other 3.7.x series branches.

...

OK, now the two things I feel are unresolved.

1) We need to figure out where CVS GNUPLOT_RELEASE_3_7_0 corresponds to 
the git master branch changeset, and create a tag 3.7.0 for that.  That 
will also be the grafting point for the 3.7.x series branch.

2) The master branch point in the attached screenshot of qgit originates 
from before beta340, beta343, etc.  I wonder if master branch should 
instead start at the point where all the other branches in that 
screenshot are emanating.  The point prior to import of beta340, etc. 
would be "Initial revision".

Dan

Re: 5.2-stable regression for log axes still not fixed completely

[Achim G. <Str...@ne...>]

Ethan A Merritt via gnuplot-beta writes:
> On Wednesday, October 25, 2017 12:47:37 PM PDT Achim Gratz wrote:
>> Achim Gratz writes:
>> > I don't really know what I'm doing, but this patch seems to fix this
>> > issue.  I don't know if it causes a regression somewhere else.
>> 
>> I#ve got a PM from Ethan about my patch, but my answer did not seem to
>> have reached him.
>
> I was deferring action because of the freeze on cvs/git commits,
> but I was planning to include a fix for this in 5.2.1 tarball even it 
> doesn't hit the source repository until the cvs->git conversion completes.

No problem, I just wasn't sure if my mail reached you.

>> One concern was about my patch ignoring the axis range.  If I'm reading
>> the code correctly, that was taken care of a few lines earlier in the
>> code when start was getting set to just below the min of the axis.
>
> The code is confusing, but it is easy enough to test what happens.
> What I see is that with your patch "as is" the first x-axis tic mark does
> not change as I gradually extend the lower end range on x.
> I added a while loop to push the start point for tic generation back
> past the lower limit. Note that the tic placement code will simply 
> ignore tics that are out of range, so placing the start point a bit
> lower than strictly necessary does not hurt. 

As I said, I didn't really know what I'm doing there, but it seemed to
fix the problem in my limited testing.

>> THe other question was about what this is trying to achieve: This is
>> about specifying a log series with undefined start and end, working on
>> an axis which has later been set up to have a defined range whose ends
>> do not coincide with the major tics.  Since the axis can start before
>> the first major tic inside its range, you must define the start to be
>> the first correct position just outside the axis min or the minor tics
>> that still lie inside the range are not visible.
>
> Right. 
> I'll send you a copy of the patch and/or a preliminary tarball offline
> if you like.

I can't test it on production code for about the next two weeks (I might
build it before), but having the patch works just fine for me, no need
for a tarball.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada