Menu
▾
▴
gnuplot-beta
|
From: <es...@th...> - 2017-10-25 17:16:37
|
I have successfully transplanted the 5.0, 4.6. and 4.4 stable
branches.
Daniel Sebald says:
>First, that oldest branch I couldn't make sense of and I think it actually may
>be bogus. Rather, it might be that those 3.x series commits should actually
>be mixed in with the master branch. We'll come back to this one.
I agree, the 3.7 branch may be unsalvageable. HBB tells me:
>3.7.1 has one check-in to ChangeLog that's tagged but not tarred, and an extra
>pair of quotes around a line in configure.in that tarred but not tagged:
But that's the last thing we need to tackle - rerooting the 4.2 and
4.0 branches comes first.
Here's what HBB and Dan think about the root points:
5.2:
HBB:
> branch-5-2-stable:1.6034.0.2
>revision 1.6034
>date: 2017/05/22 05:05:26; author: sfeam; state: Exp; lines: +5 -4170
>branches: 1.6034.2;
>Tag branchpoint for 5.2; Split off entries prior to 2016-02-07 into
>ChangeLog.5
Dan didn't weigh in on this one. It doesn't need to be rerooted;
the tag set was, apparently, complete and the join was not
displaced.
5.0:
HBB:
> branch-5-0-stable:1.5023.0.2
>revision 1.5023
>date: 2014/08/20 04:42:44; author: sfeam; state: Exp; lines: +6 -0
>branches: 1.5023.2;
>Empirical adjustments to dashlength calculated as a function of linewidth
Dan:
>[8/20/14 1:37 PM] Child: Start of separate branch for version 5 stable
>releases
>git -C branch_reference checkout 66a787634452661f02d7997a2a780165a89cedf0
>---
>MY BEST GUESS AT THE BRANCH POINT IS:
>commit 9c68a0d5f752801b536c03694cceb8e66b1122cc
>Author: Ethan A Merritt <merritt@u.washington.edu>
>Date: Tue Aug 19 21:42:44 2014 -0700
> Empirical adjustments to dashlength calculated as a function of linewidth
Ethan has confirmed that this is the correct branch point for
5-0-stable. So everybody agrees.
4.6:
HBB:
>branch-4-6-stable:1.3943.0.2
>revision 1.3943
>date: 2011/11/22 22:35:30; author: sfeam; state: Exp; lines: +3 -0
>branches: 1.3943.2;
>Try to allow for coordinate offset caused by scrolling (Firefox, Opera,
>chrome?)
Dan:
>[11/21/11 11:26 PM] Child: Bump stable version to 4.6; patchlevel is "alpha"
>git -C branch_reference checkout 88ccf09ba5b9f6042d7f2911dc1be6ae7a9aa308
>---
>MY BEST GUESS AT THE BRANCH POINT IS:
>commit df14294df51035145dc7c5391d603b0d452bcd20
>Author: Ethan A Merritt <merritt@u.washington.edu>
>Date: Tue Nov 22 21:12:06 2011 -0800
> update Bruce Ravel's contact info
>git -C root_reference checkout df14294df51035145dc7c5391d603b0d452bcd20
>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
>13 + 18
>---
>The branch-to-master diff with this is includes:
>
>diff -ur '--exclude=.git' root_reference/ChangeLog branch_reference/ChangeLog
>--- root_reference/ChangeLog 2017-10-24 21:39:21.267669735 -0500
>+++ branch_reference/ChangeLog 2017-10-24 21:31:56.447665382 -0500
>@@ -1,5 +1,10 @@
> 2011-11-22 Ethan A Merritt <xxxxxx@xxxxxx>
>
>+ * Branchpoint for 4.6
>+ cvs tag -b branch-4-6-stable
>+
>+2011-11-22 Ethan A Merritt <xxxxxx@xxxxxx>
>+
>and the first branch on master after this includes:
>
>diff --git a/ChangeLog b/ChangeLog
>index 90a47dc..d5670d7 100644
>--- a/ChangeLog
>+++ b/ChangeLog
>@@ -1,5 +1,9 @@
> 2011-11-22 Ethan A Merritt <merritt@u.washington.edu>
>
>+ * Branchpoint for 4.6 (cvs tag -b branch-4-6-stable)
>+
>+2011-11-22 Ethan A Merritt <merritt@u.washington.edu>
>+
>
>but the version number is kept at 4.5.
Dan's and HBB's choices are separated by only one commit in the
sequence, which looks like this:
2011-11-22T20:41:15Z :32059 Honor numeric locale when formatting contour lab
2011-11-22T22:35:32Z :32062 Try to allow for coordinate offset caused by scr
2011-11-22T05:26:43Z :32071 Bump stable version to 4.6; patchlevel is "alph
2011-11-23T05:12:06Z :34067 update Bruce Ravel's contact info
2011-11-22T05:08:36Z :34073 *** empty log message ***
2011-11-24T22:59:11Z :34075 LT_SINGLECOLOR flags explicit surface color
I actually wouldn't be surprised if the right root point turned out to
be the one in the middle - /Bump stable version to 4.6/. Perhaps Ethan
can clear up which one of these is right.
Note: Changing this in the conversion script is really trivial. The
relevant command sequence is
# The 4.6 branch:
/Try to allow for coordinate offset caused by/ assign v46root --singleton
/Bump stable version to 4.6;/ assign bump46 --singleton
<v46root>,<bump46> reparent --useorder --rebase
All I have to do to change the root point is edit the
selection expression in the first line.
4.4:
HBB:
> branch-4-4-stable:1.3134.0.2
>revision 1.3134
>date: 2009/05/31 19:20:09; author: sfeam; state: Exp; lines: +5 -0
>branches: 1.3134.2;
>Update
Dan:
>[5/30/09 7:30 PM] Child: Start branch for Release 4.4
>git -C branch_reference checkout e3ff538655e5b5888d9aa60b63398fc62847e46f
>---
>MY BEST GUESS AT THE BRANCH POINT IS:
>commit 65b26b2a31b4de73417d746abe96561b4655c699
>Author: Ethan A Merritt <merritt@u.washington.edu>
>Date: Sat May 30 12:20:09 2009 -0700
> Update
>git -C root_reference checkout 65b26b2a31b4de73417d746abe96561b4655c699
>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
>1 + 8
>---
>The diff includes the following:
>diff -ur '--exclude=.git' root_reference/ChangeLog branch_reference/ChangeLog
>--- root_reference/ChangeLog 2017-10-24 21:16:50.131656512 -0500
>+++ branch_reference/ChangeLog 2017-10-24 21:00:03.367646659 -0500
>@@ -1,5 +1,10 @@
> 2009-05-31 Ethan A Merritt <xxxxxx@xxxxxx>
>
>+ Start branch for Release 4.4
>+ Set VERSION to 4.4 PATCHLEVEL to alpha
>+
>+2009-05-31 Ethan A Merritt <xxxxxx@xxxxxxx>
>+
>
>and the first checkin after that is called "Branch point for version 4.4".
>Although that message would suggest it's the branchpoint, it actually has
>+ New stuff, i.e. code other than bugfixes or things identified as
>+ being desireable for version 4.4, should be commited in the
>+ development branch only (this one).
>+
>+ Bugfixes should be applied to both the development branch 4.3
>+ (this one) and the new one (branch-4-4-stable). When we release
>+ 4.4, we will bump the version number of the development branch to 4.5.
>which suggests to me that this is the first commit on master after the
>bifurcation.
HBB and Dan agree, and that agrees with what I found.
4.2:
HBB:
> branch-4-2-stable:1.2224.0.2
>revision 1.2224
>date: 2006/10/01 12:11:58; author: broeker; state: Exp; lines: +15 -7
>branches: 1.2224.2;
>Reorganize top-level configuration of automake and autoconf to allow
>version-testing automake.
Dan:
>[10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
>git -C branch_reference checkout e14ada2e7b0ae4f80d8abeffb5a27d8587a3bbed
>---
>MY BEST GUESS AT THE BRANCH POINT IS:
>commit e18d4e5da418c2ad5a98a2aff3237088aeee01c8
>Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
>Date: Sun Oct 1 17:11:57 2006 +0200
> Jump to version 4.2, 1st release candidate.
>git -C root_reference checkout e18d4e5da418c2ad5a98a2aff3237088aeee01c8
>diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| grep
>-v "^---" | wc -l
>diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| grep
>-v "^+++" | wc -l
>2 + 2
>---
>In this case HBB specifically made a note about branching.
I think Dan got this one wrong; /Jump to version 4.2/ looks to me
like branch first commit, not the root point (see the digram).
Matters are slightly complicated by the fact that that content
matches to two different commits.
2006-10-01T15:17:17Z :3688 Jump to version 4.2, 1st release candidate.
2006-10-01T15:11:57Z :22184 Jump to version 4.2, 1st release candidate.
The later one looks like a manual merge onto the mainline, so I
have rooted the earlier one to /Reorganize top-level configuration/.
4.0:
HBB:
> branch-4-0-stable:1.1148.0.2
>revision 1.1148
>date: 2004/07/02 05:03:29; author: sfeam; state: Exp; lines: +4 -0
>branches: 1.1148.2;
>#include gp_time.h
Dan:
>[7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key
>presses.
>git -C branch_reference checkout 536b2f37fdc8438459e7c7b0f44132fcd2204114
>---
>MY BEST GUESS AT THE BRANCH POINT IS:
>commit 093383fb4f9250b58d832fb10e581d90f48abb9c
>Author: Ethan Merritt <xxxxxx@xxxxxx>
>Date: Wed Jun 30 22:03:30 2004 -0700
> #include gp_time.h
>git -C root_reference checkout 093383fb4f9250b58d832fb10e581d90f48abb9c
>diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^-"| grep
>-v "^---" | wc -l
>diff -ur --exclude=".git" branch_reference/ root_reference/ | grep "^+"| grep
>-v "^+++" | wc -l
>23 + 10
>---
>The distance being quite small and the commit in master after this is
>"Renumbered head trunk version to 4.1.0", which is likely the first commit
>after the bifurcation. Note that Jun 30 is a ways from July 7, but that first
>commit on the new branch is a fix that Ethan also wanted to include in the
>stable release branch.
OK, we have agreement here.
To sum up: everyone agrees on the root points for 5.2, 5.0, 4.0, and 4.4.
I think Dan made an error locating the 4.2 root point, but I could be
wrong. We also have differing ideas about the 4.6 root.
I'm going to to do some more analysis on the 3.7 branch, but the odds
that we'll have to write it off look pretty high.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
"Rightful liberty is unobstructed action, according to our will, within limits
drawn around us by the equal rights of others."
-- Thomas Jefferson
|
|
From: <es...@th...> - 2017-10-25 22:18:47
|
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 -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> "Rightful liberty is unobstructed action, according to our will, within limits drawn around us by the equal rights of others." -- Thomas Jefferson |
|
From: Ethan A M. <sf...@us...> - 2017-10-25 23:07:13
|
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. 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. Ethan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-25 23:27:10
|
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
The actual CVS version of this file, from almost the beginning of the
public repository, to the 4.0 branch point and beyond, all the way to
almost the 4.2 branch point, was 1.1.1.2. All branches before the 4.2
one originate at revision 1.1.1.2, getting branch-point numbers like
1.1.1.2.0.{n}.
As the numbering indicates ('*.1.n', instead of '*.2.n' of ordinary
branches), this revision is from one of those pesky CVS "vendor"
pseudo-branches which the conversion tools apparently shy away from as a
vampire from garlic. Apparently Lars Hecking used "cvs import" to track
early development from his own machine(s) into the new public repository
at SF.net. That vendor branch itself is called "GNUPLOT_BETA", and all
the BETA_34* tags are on this branch.
About 2 dozen files in our project (primarily demo/*.dat) are apparently
_still_ on that branch, because they were ne7ver changed since the
initial check-in.
|
|
From: Eric S. R. <es...@th...> - 2017-10-26 03:16:24
|
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.
reposurgeon% :1008
Event 1009 ==============================================================
commit refs/tags/4.0.2
mark :1008
author Lars Hecking <lhe...@nm...> 892667807 +0100
committer Lars Hecking <lhe...@nm...> 892667807 +0100
data 26
*** empty log message ***
from :765
M 100644 :766 00test
M 100644 :767 0BUGS
:
M 100644 :836 demo/fit.dem
M 100644 :600 demo/gnuplot.rot
M 100644 :837 demo/hidden.dem
M 100644 :838 demo/mgr.dem
:
(bulk of file manifest omitted)
reposurgeon% inspect :600
Event 601 ===============================================================
blob
mark :600
data 71
zrot=(zrot+10)%360
xrot=(xrot+17)%180
set view xrot,zrot
replot
reread
The initial import brought in the short form. The longer form is in the
1998 change, which was actually a re-import of some different version of
ancestral GNUPLOT.
reposurgeon% :1369 inspect
Event 1370 ==============================================================
commit refs/tags/3.7.1
mark :1369
author Lars Hecking <lhe...@nm...> 893252459 +0100
committer Lars Hecking <lhe...@nm...> 893252459 +0100
data 20
Import of beta 344.
from :1207
M 100644 :1208 0PORTING
:
M 100644 :1222 demo/animate.dem
M 100644 :1223 demo/gnuplot.rot
M 100644 :1224 demo/multimsh.dem
:
(most of the filelist omitted)
reposurgeon% :1223 inspect
Event 1224 ==============================================================
blob
mark :1223
data 518
# 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)
replot
iteration_count=iteration_count+1
if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
Here's the 2005 change:
reposurgeon% :18499 inspect
Event 18500 =============================================================
commit refs/tags/4.2.1
mark :18499
author Daniel Sebald <dan...@ie...> 1105140062 -0800
committer Ethan A Merritt <merritt@u.washington.edu> 1136676062 -0800
data 57
Revise gif animation code to comply with Gif89a standard
from :18493
M 100644 :18494 ChangeLog
M 100644 :18495 demo/animate.dem
M 100644 :18496 demo/animate2.dem
M 100644 :18497 demo/gnuplot.rot
M 100644 :18498 term/gd.trm
reposurgeon% inspect :18497
Event 18498 =============================================================
blob
mark :18497
data 1294
# A generic rotation routine for the gnuplot view. In the commands
# that load this file, the following should be defined:
#
# iteration_count: set iteration_count=0
#
# limit_iterations: if set to a nonzero value, it'll stop after that
# many iterations; if zero value, continues indefinitely
#
# xrot: the initial x rotation of the view
#
# xrot_delta: the amount to increment the x rotation for each new plot
#
# xview: function for generating x view value; for example
# xview(xrot)=(50.+30.*sin((xrot%180)/180.*pi))
#
# zrot: the initial z rotation of the view
#
# zrot_delta: the amount to increment the z rotation for each new plot
#
# zview: function for generating z view value; for example
# zview(zrot)=(60.+45.*sin(zrot/180.*pi))
#
# History:
# - 1. 1. 2006 Dan Sebald: Made more generic so other demos could use
# - ?. ?. ? Hans-Bernhard Broeker: Used to just turn round and round
# by somewhat large steps. Now, it tumbles back and forth
# smoothly.
# - ?. ?. ? ?: Initial recursive script
iteration_count=iteration_count+1
if ((!limit_iterations) || (iteration_count<=limit_iterations)) \
set view xview(xrot),zview(zrot); \
replot; \
zrot=(zrot+zrot_delta)%360; \
xrot=(xrot+xrot_delta)%360; \
reread
> 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.
This is not a conversion problem. It's not even like the 4.2/4.4/4.6
branches, where an incomplete root-tag set threw the join point
backwards in time. This is somebody's finger error that's been lurking
in the repo metadata since the 4.0 branch was forked from the wrong
place.
As such, our options for fixing it are limited and unpleasant.
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.
The second option would be to leave the mess as it is. I dislike this plan
for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state
does not match the archived tarball.
The third option is the heroic, possibly overinvested one. I could insert
a synthetic commit between the master-branch root of 4.0 and the rest
replicating the X change to gnuplot.rot, with a change comment explaining
the mess. Then we could try to rectify the 3.7.x branch.
You guys are the customer, you get to decide.
--
<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.
|
|
From: Daniel J S. <dan...@ie...> - 2017-10-26 18:35:12
|
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 |
|
From: sfeam <sf...@us...> - 2017-10-26 03:52:10
|
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
[shrug] In CVS view on SourceForge that revision "Revise gif animation code ..."
has timestamp
Sat Jan 7 23:21:02 2006 UTC (11 years, 9 months ago) by sfeam
http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/demo/gnuplot.rot?revision=1.2&view=markup
Nothing before that all the way to 1998.
Ethan
>
> 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.
>
> reposurgeon% :1008
> Event 1009 ==============================================================
> commit refs/tags/4.0.2
> mark :1008
> author Lars Hecking <lhe...@nm...> 892667807 +0100
> committer Lars Hecking <lhe...@nm...> 892667807 +0100
> data 26
> *** empty log message ***
> from :765
> M 100644 :766 00test
> M 100644 :767 0BUGS
> :
> M 100644 :836 demo/fit.dem
> M 100644 :600 demo/gnuplot.rot
> M 100644 :837 demo/hidden.dem
> M 100644 :838 demo/mgr.dem
> :
> (bulk of file manifest omitted)
> reposurgeon% inspect :600
> Event 601 ===============================================================
> blob
> mark :600
> data 71
> zrot=(zrot+10)%360
> xrot=(xrot+17)%180
> set view xrot,zrot
> replot
> reread
>
> The initial import brought in the short form. The longer form is in the
> 1998 change, which was actually a re-import of some different version of
> ancestral GNUPLOT.
>
> reposurgeon% :1369 inspect
> Event 1370 ==============================================================
> commit refs/tags/3.7.1
> mark :1369
> author Lars Hecking <lhe...@nm...> 893252459 +0100
> committer Lars Hecking <lhe...@nm...> 893252459 +0100
> data 20
> Import of beta 344.
> from :1207
> M 100644 :1208 0PORTING
> :
> M 100644 :1222 demo/animate.dem
> M 100644 :1223 demo/gnuplot.rot
> M 100644 :1224 demo/multimsh.dem
> :
> (most of the filelist omitted)
> reposurgeon% :1223 inspect
> Event 1224 ==============================================================
> blob
> mark :1223
> data 518
> # 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)
> replot
> iteration_count=iteration_count+1
> if ((!limit_iterations) || (iteration_count<=limit_iterations)) reread
>
> Here's the 2005 change:
>
> reposurgeon% :18499 inspect
> Event 18500 =============================================================
> commit refs/tags/4.2.1
> mark :18499
> author Daniel Sebald <dan...@ie...> 1105140062 -0800
> committer Ethan A Merritt <merritt@u.washington.edu> 1136676062 -0800
> data 57
> Revise gif animation code to comply with Gif89a standard
> from :18493
> M 100644 :18494 ChangeLog
> M 100644 :18495 demo/animate.dem
> M 100644 :18496 demo/animate2.dem
> M 100644 :18497 demo/gnuplot.rot
> M 100644 :18498 term/gd.trm
>
> reposurgeon% inspect :18497
> Event 18498 =============================================================
> blob
> mark :18497
> data 1294
> # A generic rotation routine for the gnuplot view. In the commands
> # that load this file, the following should be defined:
> #
> # iteration_count: set iteration_count=0
> #
> # limit_iterations: if set to a nonzero value, it'll stop after that
> # many iterations; if zero value, continues indefinitely
> #
> # xrot: the initial x rotation of the view
> #
> # xrot_delta: the amount to increment the x rotation for each new plot
> #
> # xview: function for generating x view value; for example
> # xview(xrot)=(50.+30.*sin((xrot%180)/180.*pi))
> #
> # zrot: the initial z rotation of the view
> #
> # zrot_delta: the amount to increment the z rotation for each new plot
> #
> # zview: function for generating z view value; for example
> # zview(zrot)=(60.+45.*sin(zrot/180.*pi))
> #
> # History:
> # - 1. 1. 2006 Dan Sebald: Made more generic so other demos could use
> # - ?. ?. ? Hans-Bernhard Broeker: Used to just turn round and round
> # by somewhat large steps. Now, it tumbles back and forth
> # smoothly.
> # - ?. ?. ? ?: Initial recursive script
>
> iteration_count=iteration_count+1
> if ((!limit_iterations) || (iteration_count<=limit_iterations)) \
> set view xview(xrot),zview(zrot); \
> replot; \
> zrot=(zrot+zrot_delta)%360; \
> xrot=(xrot+xrot_delta)%360; \
> reread
>
> > 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.
>
> This is not a conversion problem. It's not even like the 4.2/4.4/4.6
> branches, where an incomplete root-tag set threw the join point
> backwards in time. This is somebody's finger error that's been lurking
> in the repo metadata since the 4.0 branch was forked from the wrong
> place.
>
> As such, our options for fixing it are limited and unpleasant.
>
> 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.
>
> The second option would be to leave the mess as it is. I dislike this plan
> for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state
> does not match the archived tarball.
>
> The third option is the heroic, possibly overinvested one. I could insert
> a synthetic commit between the master-branch root of 4.0 and the rest
> replicating the X change to gnuplot.rot, with a change comment explaining
> the mess. Then we could try to rectify the 3.7.x branch.
>
> You guys are the customer, you get to decide.
>
|
|
From: Eric S. R. <es...@th...> - 2017-10-26 04:06:49
|
sfeam <sf...@us...>: > > 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 > > [shrug] In CVS view on SourceForge that revision "Revise gif animation code ..." > has timestamp > Sat Jan 7 23:21:02 2006 UTC (11 years, 9 months ago) by sfeam > > http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/demo/gnuplot.rot?revision=1.2&view=markup > > Nothing before that all the way to 1998. That's weird. gitk says 2005, too. I'll look into this further. It doesn't make any difference to the present mess, though; both dates are too late at the 2005/2006 commit is on the wrong branch. 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. The second option would be to leave the mess as it is. I dislike this plan for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state does not match the archived tarball. The third option is the heroic, possibly overinvested one. I could insert a synthetic commit between the master-branch root of 4.0 and the rest replicating the X change to gnuplot.rot, with a change comment explaining the mess. Then we could try to rectify the 3.7.x branch. -- <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. |
|
From: sfeam <sf...@us...> - 2017-10-26 04:37:30
|
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. > The second option would be to leave the mess as it is. I dislike this plan > for one major reason: We know the 3.7.x branch is corrupt - its 3.7.1 state > does not match the archived tarball. At least we _have_ tarballs for 3.7.1 3.7.2 3.7.3 They can be accessed as-is. I can't find tarballs for anything between 4.0.0 and 4.2.0 anywhere on the web. Ethan > The third option is the heroic, possibly overinvested one. I could insert > a synthetic commit between the master-branch root of 4.0 and the rest > replicating the X change to gnuplot.rot, with a change comment explaining > the mess. Then we could try to rectify the 3.7.x branch. > |
|
From: Daniel J S. <dan...@ie...> - 2017-10-26 07:37:47
|
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 |
|
From: sfeam <sf...@us...> - 2017-10-26 16:32:18
|
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 |
|
From: Eric S. R. <es...@th...> - 2017-10-26 16:50:31
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-26 16:50:39
|
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 |
|
From: Ethan A M. <sf...@us...> - 2017-10-26 17:40:18
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2017-10-26 17:57:53
|
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 |
|
From: Eric S. R. <es...@th...> - 2017-10-26 18:42:45
|
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. |
|
From: Eric S. R. <es...@th...> - 2017-10-27 01:35:13
|
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.
|
|
From: Daniel J S. <dan...@ie...> - 2017-10-27 08:57:14
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2017-10-27 16:50:14
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2017-10-27 17:40:48
|
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
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-27 20:09:40
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-27 20:35:17
|
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 |
|
From: Eric S. R. <es...@th...> - 2017-10-27 20:28:14
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-27 20:43:55
|
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
|
|
From: Petr M. <mi...@ph...> - 2017-10-27 20:47:13
|
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. |
