Menu
▾
▴
gnuplot-beta
|
From: Eric S. R. <es...@th...> - 2017-10-28 17:41:48
|
Petr Mikulik <mi...@ph...>: > Those "beta 3xy" are patchlevels of gnuplot 3.6, not patchlevels of gnuplot > 3.4. Thanks, the annotations now reflect this. -- <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: Hans-Bernhard B. <HBB...@t-...> - 2017-10-27 22:16:42
|
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. |
|
From: Eric S. R. <es...@th...> - 2017-10-28 03:58:28
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-27 23:01:51
|
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
|
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-27 23:38:15
|
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. |
|
From: Eric S. R. <es...@th...> - 2017-10-28 04:03:02
|
Daniel J Sebald <dan...@ie...>: > >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? I don't understrand your terminology. It's not at all difficult to rebase a branch root, if that's what you're asking. -- <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: Hans-Bernhard B. <HBB...@t-...> - 2017-10-27 23:04:07
|
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.
|
|
From: Eric S. R. <es...@th...> - 2017-10-28 17:51:08
|
Hans-Bernhard Bröker <HBB...@t-...>:
> 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].
On the one hand, that 3.7.0 would be interesting - might help us tag the
corresponding point in the repository. On the other hand, I'm not getting
a good feeling from Dan's reports on his attempts to disentangle that branch.
We know it's corrupt - doesn't have the right tip state.
I'd be just as happy to drop it at this point
Sigh...you should probably sent us both copies of 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.
Except it seems to have become confounded with the 3.7.x branch we have.
--
<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-28 18:48:33
|
On 10/28/2017 12:51 PM, Eric S. Raymond wrote:
> Hans-Bernhard Bröker <HBB...@t-...>:
>> 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].
>
> On the one hand, that 3.7.0 would be interesting - might help us tag the
> corresponding point in the repository. On the other hand, I'm not getting
> a good feeling from Dan's reports on his attempts to disentangle that branch.
> We know it's corrupt - doesn't have the right tip state.
>
> I'd be just as happy to drop it at this point
>
> Sigh...you should probably sent us both copies of 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.
>
> Except it seems to have become confounded with the 3.7.x branch we have.
I've dug into the actual ./reconvert process a bit. I'm bewildered by
some fundamental things regarding the CVS repository on
:pserver:ano...@gn...:/cvsroot/gnuplot
I assume that this repository is the same that is used to get the CVS
copy used in the ./reconvert process
cvssync -c gnuplot.cvs.sourceforge.net:/cvsroot/gnuplot gnuplot
mv gnuplot gnuplot-cvs
Those are the same repository, correct?
OK, I've been comparing the gnuplot-git repository against "cvs update
-rGNUPLOT_3_7_0" and so on. As I pointed out I've often gotten good
matches in terms of code mods, with the exception being all these RCSid
strings.
I see now how that "drd" is finding its way into the git repository.
The cvssync gets the repository in archival form to the local system
into gnuplot-cvs. In there is the history for the ./alloc.c file, and
I'll extract the pertinent references to "drd":
1.2
log
@Fix segfault.
@
text
@d2 1
a2 1
static char *RCSid = "$Id: alloc.c,v 1.12 1998/03/22 22:31:16 drd Exp $";
@
1.1
log
@Initial revision
@
text
@d2 1
a2 1
static char *RCSid = "$Id: alloc.c,v 1.11 1997/04/10 02:32:39 drd Exp $";
1.1.1.2
log
@Import of beta 343.
@
text
@d2 1
a2 1
static char *RCSid = "$Id: alloc.c,v 1.12 1998/03/22 22:31:16 drd Exp $";
Now, when I get the ./alloc.c file remotely from the server with "cvs" I
get the following RCSid strings:
cvs update -r1.1 alloc.c
(yields)
static char *RCSid = "$Id: alloc.c,v 1.1 1998/04/15 19:16:27 lhecking
Exp $";
cvs update -r1.2 alloc.c
(yields)
static char *RCSid = "$Id: alloc.c,v 1.2 1999/03/23 12:21:51 lhecking
Exp $";
cvs update -r1.1.1.2 alloc.c
(yields)
static char *RCSid = "$Id: alloc.c,v 1.1.1.2 1998/04/15 19:21:56
lhecking Exp $";
Why are these strings not matching what is listed in the gnuplot-cvs files?
Perhaps this has something to do with this
# In order not to introduce noise into tree comparisons, you must
specify the
# argument 'finish' to do the part of the conversion that involves checking
# in the FAQ and patching out the RCS cookies
[snip]
#
# Also requires patch files COOKIEPATCH
#
Is there something about the file COOKIEPATCH possibly missing some
fixes needed for files tucked away in the Attic?
I agree these RCSid aren't that important, but it sure would be a nice
feeling to have a match between, say, "cvs update -rXYZ" and "git
checkout XYZ" from remote locations.
Dan
|
|
From: Ethan A M. <sf...@us...> - 2017-10-25 18:52:11
|
On Wednesday, October 25, 2017 10:16:29 AM PDT Eric S. Raymond wrote: > 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/. The logical branch point for branch-4-2-stable would have been immediately before the 2006-10-01 "jump to version 4.2" commit. e18d4e5da418c2ad5a98a2aff3237088aeee01c8 I don't know whether the "branch point" terminology used by git refers to the last common ancester or the first commit after divergence. Looks like "jump to version 4.2" is the latter (first commit after split), while "re-organize top level configuration" is the former (last common ancestor). Ethan |
|
From: Eric S. R. <es...@th...> - 2017-10-25 19:30:42
|
Ethan A Merritt <sf...@us...>: > The logical branch point for branch-4-2-stable would have been immediately > before the 2006-10-01 "jump to version 4.2" commit. > e18d4e5da418c2ad5a98a2aff3237088aeee01c8 > > I don't know whether the "branch point" terminology used by git > refers to the last common ancester or the first commit after divergence. > Looks like "jump to version 4.2" is the latter (first commit after split), > while "re-organize top level configuration" is the former (last common > ancestor). Yes, that is how I have rearranged the tree. Usually, "branch point" refers to the common ancestor. But it is wise to be careful about this, as noyt all usage is consistent. I'm working on 4.0 now. -- <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-25 19:48:52
|
On 10/25/2017 12:16 PM, Eric S. Raymond wrote:
[snip]
> 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.
4.2: Yes, I think I'm wrong there, having a second look. I agree that
the first two commits on trunk and branch having the same version number
change is slightly odd (root uses the word "Changed" where branch uses
the word "Bumped"), but different people do things differently.
However, there are two checkins of the same message: "Jump to version
4.2, 1st release candidate." One wouldn't branch off of a point and use
the same message for the first change. So the branch point is
Author: Hans-Bernhard Broeker <xxxxxx@xxxxxx>
Date: Sun Oct 1 14:11:58 2006 +0200
Reorganize top-level configuration of automake and autoconf...
...to allow version-testing automake.
4.6: I think I could go along with your choice on this one as well. It
looks to me that Ethan first prepped for the branch by updating dates in
the checkin "*** empty log message ***", but didn't change the actual
version number at that time. Bifurcating at this point would have the
updated version number on the 4.6 branch as the first change, whereas
the trunk's first change is continued development and nothing to do with
version number. I was looking for a common pattern of branching I
guess, but as noted different people do things differently. So, yeah,
the branch point is
*** empty log message ***
Ethan A Merritt<xxxxxx@xxxxxx>
11/21/11 11:08 PM
but note that this author date (not commit date) is 11/21 where the
previous change is 11/22. The commit date (11/23 or 11/24 depending on
time zone) seems to be in order though.
> 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.
I'll look at this a bit more. For those with historical knowledge, I'm
going to write some checkin comments here that come from searching, but
only those that seem like they could give a clue about when the first
branch was done. (I'm using qgit, which has some nice searching and
file features.) Let me know if they ring a bell:
"branch"
New function gp_strdup, from cvs MAIN branch.
Updated from cvs MAIN branch
New files from my branched-off 'monster patch'
Merged the pm3d branch back to MAIN
Merge axis-branch into MAIN. Lots of changes all over the places
a few changes after merging the axis branch
make the branched version compile under OS/2
Updated from aquaterm cvs bugfix branch.
"merge"
Final fixes for merger.
Update from current automake (lost in merge).
Some cleanups/fixes after the merge.
Dan
|
|
From: Eric S. R. <es...@th...> - 2017-10-25 20:57:06
|
Daniel J Sebald <dan...@ie...>: > 4.2: Yes, I think I'm wrong there, having a second look. > 4.6: I think I could go along with your choice on this one as well. OK. I'm working on 4.0. I've run into a minor bug in reposurgeon that I need to fix. > >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. > > I'll look at this a bit more. For those with historical knowledge, I'm > going to write some checkin comments here that come from searching, I'll want those to patch in, of course. -- <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-25 23:59:52
|
On 10/25/2017 02:48 PM, Daniel J Sebald wrote: > On 10/25/2017 12:16 PM, Eric S. Raymond wrote: [snip] >> 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. > > I'll look at this a bit more. For those with historical knowledge, I'm > going to write some checkin comments here that come from searching, but > only those that seem like they could give a clue about when the first > branch was done. (I'm using qgit, which has some nice searching and > file features.) Let me know if they ring a bell: > > "branch" > New function gp_strdup, from cvs MAIN branch. > Updated from cvs MAIN branch > New files from my branched-off 'monster patch' > Merged the pm3d branch back to MAIN > Merge axis-branch into MAIN. Lots of changes all over the places > a few changes after merging the axis branch > make the branched version compile under OS/2 > Updated from aquaterm cvs bugfix branch. > > "merge" > Final fixes for merger. > Update from current automake (lost in merge). > Some cleanups/fixes after the merge. Here's a bit of a clue about the branch point for that first branch. I noted that the two files that had changed with the "Windows linestyle fix." checkin are: ============================================================================= RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v Working file: win/wgnuplib.h head: 1.6 branch: ---------------------------- revision 1.4.2.1 date: 1999/08/19 14:13:09; author: lhecking; state: Exp; lines: +4 -1 Windows linestyle fix. ============================================================================= ============================================================================= RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgraph.c,v Working file: win/wgraph.c head: 1.7 branch: ---------------------------- revision 1.5.2.1 date: 1999/08/19 14:13:09; author: lhecking; state: Exp; lines: +12 -1 Windows linestyle fix. ============================================================================= However, compare the date with the following major modification which moved those files from the win/ directory to the win/src directory (and remember in CVS the "move" is actually as though these are completely different files, with new instantiation): ============================================================================= RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v Working file: win/wgnuplib.h head: 1.6 branch: ---------------------------- revision 1.6 date: 1999/03/26 22:09:29; author: lhecking; state: dead; lines: +1 -1 Moved to src/win/. ---------------------------- ============================================================================= So, that modification "Windows linestyle fix" is dated five months *after* the file was moved, effectively terminated. There is no way the branch point could be near 1999/08/19 where I was searching. So, no surprise that search failed. I've searched back much earlier. I'm not familiar with CVS versioning, does the "revision 1.4.2.1 date: 1999/08/19 14:13:09;" mean that this particular revision was derived from "revision 1.4"? I.e., the user checked out "revision 1.4" as a start for creating the branch? In this case revision 1.4 was of ---------------------------- revision 1.4 date: 1998/12/10 18:30:13; author: lhecking; state: Exp; lines: +0 -2 branches: 1.4.2; Remove two defines. ---------------------------- So, maybe that is where I should look, around 1998/12/10. (I should probably just write a script to compare against all versions.) ... Nope. If I'm understanding correctly, based upon the "branches" number of 1.4.2.1, "Windows linestyle fix" could have happened any time between revision 1.5 (1999/02/14 18:13:55) and revision 1.4 (1998/12/10 18:30:13). The logical branch points in that range would be date: 1999/01/12 14:03:53; author: lhecking; state: Exp; lines: +4 -5 Version 3.7, patchlevel 0, update date string. and date: 1999/01/12 13:58:02; author: lhecking; state: Exp; lines: +3 -3 Updated to 3.7. but again, those don't seem to match well. Well, here's one encouraging result: I've done the directory comparison between CVS versions. If I pick CVS directory to be cvs update -rGNUPLOT_RELEASE_3_7_0 and compare against the git "Windows linestyle fix." directory it creates pretty good agreement but it looks like all the RCSid are rather different. Just to illustrate, here a diff of one of the files that supposedly changes both within CVS and across CVS and git: sebald@ ~/gnuplot/git_translation/branch_point_search/gnuplot $ cvs diff -u -r1.4 -r1.4.2.1 win/wgnuplib.h Index: win/wgnuplib.h =================================================================== RCS file: /cvsroot/gnuplot/gnuplot/win/Attic/wgnuplib.h,v retrieving revision 1.4 retrieving revision 1.4.2.1 diff -u -r1.4 -r1.4.2.1 --- win/wgnuplib.h 10 Dec 1998 18:30:13 -0000 1.4 +++ win/wgnuplib.h 19 Aug 1999 14:13:09 -0000 1.4.2.1 @@ -1,5 +1,5 @@ /* - * $Id: wgnuplib.h,v 1.4 1998/12/10 18:30:13 lhecking Exp $ + * $Id: wgnuplib.h,v 1.4.2.1 1999/08/19 14:13:09 lhecking Exp $ */ /* GNUPLOT - win/wgnuplib.h */ @@ -320,6 +320,9 @@ HPEN hbpen; /* border pen */ HPEN hapen; /* axis pen */ HPEN hpen[WGNUMPENS]; /* pens */ +#if 1 /* HBB 980118: new try ... */ + HPEN hsolidpen[WGNUMPENS]; /* solid pens (for point symbols) */ +#endif LOGPEN colorpen[WGNUMPENS+2]; /* logical color pens */ LOGPEN monopen[WGNUMPENS+2]; /* logical mono pens */ COLORREF background; /* background color */ sebald@ ~/gnuplot/git_translation/branch_point_search $ diff -ur --exclude=".git" gnuplot/win/wgnuplib.h branch_reference/win/wgnuplib.h --- gnuplot/win/wgnuplib.h 1998-12-10 12:30:13.000000000 -0600 +++ branch_reference/win/wgnuplib.h 2017-10-25 16:05:19.318473813 -0500 @@ -320,6 +320,9 @@ HPEN hbpen; /* border pen */ HPEN hapen; /* axis pen */ HPEN hpen[WGNUMPENS]; /* pens */ +#if 1 /* HBB 980118: new try ... */ + HPEN hsolidpen[WGNUMPENS]; /* solid pens (for point symbols) */ +#endif LOGPEN colorpen[WGNUMPENS+2]; /* logical color pens */ LOGPEN monopen[WGNUMPENS+2]; /* logical mono pens */ COLORREF background; /* background color */ The discouraging part, though, is that when I compare CVS GNUPLOT_RELEASE_3_7_0 against git master commit "Updated to 3.7.", it's not a good match at all. Shouldn't it be a good match? I think the key here is to first figure out and reconstruct what would be tag 3.7.0 in the git repository, so that it coincides with GNUPLOT_RELEASE_3_7_0. It might be the something is corrupted in the master branch in that first few years of checkins. My guess would be that release 3.7.0 was on the trunk, then "Windows linestyle fix" was a branch, which produced 3.7.1, 3.7.2, etc. I can see why this is so difficult to reconstruct now. Tags are the only sort of reliable CVS construct, so I suppose we should get those important ones working first. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-10-29 19:01:36
|
I've experimented with something called cvs2git, which I believe does a pretty good job of constructing branches and merges, but has some drawbacks. All I did was follow the instructions here: http://cvs2svn.tigris.org/cvs2git.html with the exception I had to create a link cvs2git-tmp to cvs2svn-tmp because the program (based off cvs2svn) was erroring out when it couldn't find the blob and dump files in a non-existent cvs2git-tmp directory. (Surely a bug in the version I have, maybe not present in more recent releases.) cvs2svn takes about forty five minutes to run (creates a mondo blob file), so have something else to work on in the meantime. It's major drawbacks are: 1) No corrected author info. 2) All of the RCSid strings are replaced by empty string, e.g., diff -ur '--exclude=.git' /home/sebald/gnuplot/gnuplot/gnuplot/time.c gnuplot/time.c --- /home/sebald/gnuplot/gnuplot/gnuplot/time.c 2017-10-28 22:16:04.820853058 -0500 +++ gnuplot/time.c 2017-10-28 22:18:35.340854531 -0500 @@ -1,5 +1,5 @@ #ifndef lint -static char *RCSid = "$Id: time.c,v 1.5 1998/12/09 15:25:54 lhecking Exp $"; +static char *RCSid = "$Id$"; #endif which makes it even worse than the differences I'm now seeing. 3) It seems to get the tags at the start of the repository wrong, even though the branches look correct. At least cvs2git is a good guide for branching, and I'm wondering if we can use reposurgeon on the cvs-fast-export result to make the branching match cvs2git. (I did this last night.) In contrast, I would summarize cvs-fast-export's deficiencies as follows: 1) I think cvs-fast-export is getting hung up on the scenario by which the "Initial import of beta340." branch is the exact same time as the "Initial revision". That is, all the files in the "Initial import of beta340." group match "Initial revision" as follows (same time, and zero lines difference): ---------------------------- revision 1.1 date: 1998/04/15 19:16:47; author: lhecking; state: Exp; branches: 1.1.1; Initial revision ---------------------------- revision 1.1.1.1 date: 1998/04/15 19:16:47; author: lhecking; state: Exp; lines: +0 -0 Initial import of beta340. ---------------------------- I'm not quite sure how Lars managed that. Nonetheless, the conversion program has to pick a name to use here. As does cvs2git, cvs-fast-export picks "Initial import of beta340.". But cvs2git recognizes this is a branch (still no files) and then does "Import of beta 343" (containing files) and merges back into the master branch with a comment such as " This commit was generated by cvs2svn to compensate for changes in r5, which included commits to RCS files with non-trunk default branches. " It does the same thing with "Import of beta 344.", "Import of beta 345.", "Import of beta 346." and then later something from "Initial import of beta340." So, yes, it's complex and it is best to have the cvs2git result handy to understand this, but it makes clear the system Lars was using as described by HBB, i.e., vendor branches. I'm wondering if we can just use reposurgeon to reconstruct that series of branches and merges. What cvs-fast-export does do for those tricky utility-branches is put in the extra *** empty log message *** probably because of the time span of the cvs initial checkins. (Recall, 1999 computers were much slower than today, so the file time stamps are spread out over 30 seconds. We need a wide fuzz-factor and if Lars did some action immediately after that first CVS creation command, something could get pulled into the first collection.) Anyway, somehow the *** empty log message *** appears to adjust things, and for cvs-fast-export we get: *** empty log message *** (no files) Initial import of beta340. (no files) *** empty log message *** (has files) Initial import of beta340. (deletes some of those files) Synthetic commit for tag BETA_340 (puts those files back in) Import of beta 343. (mostly modifications) Synthetic commit for tag BETA_343 (adds files back in) *** empty log message *** (master branch start, has files) Include stdfn.h. (adds just one file) In contrast cvs2git has the following first changesets: Initial import of beta340. (no files) Import of beta 343. (has files) This commit was manufactured by cvs2svn to create branch 'GNUPLOT_BETA'. (has two files) Import of beta 344. (all modifications) Import of beta 345. (all modifications) Import of beta 346. (all modifications) Import of beta 347. (all modifications) This commit was generated by cvs2svn to compensate for changes in r2, which included commits to RCS files with non-trunk default branches. (no files) This commit was generated by cvs2svn to compensate for changes in r5, which included commits to RCS files with non-trunk default branches. (merge files into master branch) Include stdfn.h. (adds just one file) The above cvs2git arrangement looks a lot like Eric's original repository result, except that result was missing the merge back into master branch. So, the ./reconvert file. I'm going to email Eric a diff file of the changes I've made. 1) I've restored all the tags and branches, at least for the time being, so that I could compare cvs-fast-export to cvs2git with greater detail. Honestly, my preference would be to keep all tags, and I'd prefer that HBB and Ethan (et al.) have a chance to see the full repository in a git viewer first (I recommend qgit for this) before deciding to cut things out. I like having the tags GNUPLOT_RELEASE_3_7_0, etc. and maybe instead we could just add additional tags 3.7.0, etc. alongside the original. HBB and Ethan should be able to run Eric's ./reconvert script to generate the repository (it's just one command), so there's no need to post any new repository to SourceForge. (And creating the cvs2git version isn't too difficult either. Just use as an input to cvs2git the gnuplot-cvs directory created by Eric's ./reconvert script.) 2) I used cvs2git's branch points in directives for reposurgeon. (Yes, stuff like /Initial import of 3.6 beta340./ assign root37 @min(/New file.$/),<root37> reparent --use-order --rebase (My learning curve was understanding various syntax in order to create singletons.) After having done the above, I find that tree-wise the two conversions look similar, except for the first dozen changesets. cvs2git has more logical file changes at the rebased branch point: the diffs look correct, but I suspect the difference at the start of the repo result in other files being swept in. Tag-wise, again very similar ("cvs2git created this branch for a tag", etc. coincides well with "cvs-fast-export created this branch for a tag"). However, I think cvs-fast-export is a little better at this at the start of the repo than cvs2git. And exact file matches between the two conversions is difficult because cvs2git drops all the RCSid strings. (We'll make sure all those things are gone from the start of the new repo, which Eric may have already done.) 3) I commented out the pre-CVS archival changesets for the time being. I think we should just concentrate on that initial dozen changesets (try to match cvs2git more, I couldn't figure out how to add merges via reposurgeon), and if we get those cleared up my hope is that it works its way through the whole tree and fixes up the branches without the need of shims. Dan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-29 20:16:34
|
Am 29.10.2017 um 20:01 schrieb Daniel J Sebald:
> I've experimented with something called cvs2git, which I believe does a
> pretty good job of constructing branches and merges, but has some
> drawbacks.
[...]
> It's major drawbacks are:
>
> 1) No corrected author info.
>
> 2) All of the RCSid strings are replaced by empty string, e.g.,
That's not a drawback; it's a necessary consequence of moving to git.
One way or another, all these strings (technically: RCS-style keywords)
have to go.
For comparisons of working copies, I would therefore strongly recommend
adding an appropriate ignore option to 'diff', such as
diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*'
to avoid getting side-tracked.
> In contrast, I would summarize cvs-fast-export's deficiencies as follows:
>
> 1) I think cvs-fast-export is getting hung up on the scenario by which
> the "Initial import of beta340." branch is the exact same time as the
> "Initial revision".
> I'm not quite sure how Lars managed that.
Lars just used the feature of CVS advertised for the job he was doing at
the time: "cvs import". This creates a vendor branch, which behaves
rather differently from ordinary branches. One side effect of that is
that the 1.1 revisions ("Initial revision") of all files that existed at
the time have another revision at the exact same time, numbered 1.1.1.1,
on the vendor branch.
These 1.1 revisions really only exist as an anchor point for the vendor
branch --- they never appear in working copies. You can still see that
today: files that already existed back then, and never changed since,
still have revision 1.1.1.1:
$ cvs status demo/world.cor
===================================================================
File: world.cor Status: Up-to-date
Working revision: 1.1.1.1
Repository revision: 1.1.1.1 /cvsroot/gnuplot/gnuplot/demo/world.cor,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
One weird aspect of vendor branches is that the first modification of
such a file will not get revision number 1.1.1.2, as might be expected,
but rather 1.2. That's because revision 1.1.1.2 is reserved for the
next "cvs import".
|
|
From: Eric S. R. <es...@th...> - 2017-10-31 19:20:16
|
Hans-Bernhard Bröker <HBB...@t-...>: > Am 29.10.2017 um 20:01 schrieb Daniel J Sebald: > >I've experimented with something called cvs2git, which I believe does a > >pretty good job of constructing branches and merges, but has some > >drawbacks. > [...] > >It's major drawbacks are: > > > >1) No corrected author info. > > > >2) All of the RCSid strings are replaced by empty string, e.g., > > That's not a drawback; it's a necessary consequence of moving to git. One > way or another, all these strings (technically: RCS-style keywords) have to > go. There's a late step in reconvert that does exactly that. -- <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-29 20:34:33
|
On Sunday, 29 October 2017 14:01:15 Daniel J Sebald wrote: > I've experimented with something called cvs2git, which I believe does a > pretty good job of constructing branches and merges, but has some > drawbacks. I think we are past the stage of looking for alternative conversion utilities. Can't we just flatten everything prior to version 4.0 into a baseline snapshot that is the root for everything subsequent to that? I really don't see why anyone will ever need to modify or branch from anything prior to 4.0. The tarballs are good enough for historical reference. I just don't see why anyone would care about the branch structure of 3.4/3.5/3.7/3.8 now that it's 20 years done and over. And if someone _does_ want the historical information for some reason other than development going forward, they would do better to go back to the archived cvs repository itself rather than having to deal with any post-processing layers you might add now to make the cvs->git conversion work. I suggest that at this point the only issue worth spending more time on is authorship attributions transferred from the ChangeLog series. Once that is sorted out, let's call it a wrap. Ethan > All I did was follow the instructions here: > http://cvs2svn.tigris.org/cvs2git.html > with the exception I had to create a link cvs2git-tmp to cvs2svn-tmp > because the program (based off cvs2svn) was erroring out when it > couldn't find the blob and dump files in a non-existent cvs2git-tmp > directory. (Surely a bug in the version I have, maybe not present in > more recent releases.) cvs2svn takes about forty five minutes to run > (creates a mondo blob file), so have something else to work on in the > meantime. > > It's major drawbacks are: > > 1) No corrected author info. > > 2) All of the RCSid strings are replaced by empty string, e.g., > > diff -ur '--exclude=.git' /home/sebald/gnuplot/gnuplot/gnuplot/time.c > gnuplot/time.c > --- /home/sebald/gnuplot/gnuplot/gnuplot/time.c 2017-10-28 > 22:16:04.820853058 -0500 > +++ gnuplot/time.c 2017-10-28 22:18:35.340854531 -0500 > @@ -1,5 +1,5 @@ > #ifndef lint > -static char *RCSid = "$Id: time.c,v 1.5 1998/12/09 15:25:54 lhecking > Exp $"; > +static char *RCSid = "$Id$"; > #endif > > which makes it even worse than the differences I'm now seeing. > > 3) It seems to get the tags at the start of the repository wrong, even > though the branches look correct. > > > At least cvs2git is a good guide for branching, and I'm wondering if we > can use reposurgeon on the cvs-fast-export result to make the branching > match cvs2git. (I did this last night.) > > In contrast, I would summarize cvs-fast-export's deficiencies as follows: > > 1) I think cvs-fast-export is getting hung up on the scenario by which > the "Initial import of beta340." branch is the exact same time as the > "Initial revision". That is, all the files in the "Initial import of > beta340." group match "Initial revision" as follows (same time, and zero > lines difference): > > ---------------------------- > revision 1.1 > date: 1998/04/15 19:16:47; author: lhecking; state: Exp; > branches: 1.1.1; > Initial revision > ---------------------------- > revision 1.1.1.1 > date: 1998/04/15 19:16:47; author: lhecking; state: Exp; lines: +0 -0 > Initial import of beta340. > ---------------------------- > > I'm not quite sure how Lars managed that. Nonetheless, the conversion > program has to pick a name to use here. As does cvs2git, > cvs-fast-export picks "Initial import of beta340.". But cvs2git > recognizes this is a branch (still no files) and then does "Import of > beta 343" (containing files) and merges back into the master branch with > a comment such as > > " > This commit was generated by cvs2svn to compensate for changes in r5, > which included commits to RCS files with non-trunk default branches. > " > > It does the same thing with "Import of beta 344.", "Import of beta > 345.", "Import of beta 346." and then later something from "Initial > import of beta340." So, yes, it's complex and it is best to have the > cvs2git result handy to understand this, but it makes clear the system > Lars was using as described by HBB, i.e., vendor branches. I'm > wondering if we can just use reposurgeon to reconstruct that series of > branches and merges. > > What cvs-fast-export does do for those tricky utility-branches is put in > the extra *** empty log message *** probably because of the time span of > the cvs initial checkins. (Recall, 1999 computers were much slower than > today, so the file time stamps are spread out over 30 seconds. We need > a wide fuzz-factor and if Lars did some action immediately after that > first CVS creation command, something could get pulled into the first > collection.) Anyway, somehow the *** empty log message *** appears to > adjust things, and for cvs-fast-export we get: > > *** empty log message *** (no files) > Initial import of beta340. (no files) > *** empty log message *** (has files) > Initial import of beta340. (deletes some of those files) > Synthetic commit for tag BETA_340 (puts those files back in) > Import of beta 343. (mostly modifications) > Synthetic commit for tag BETA_343 (adds files back in) > *** empty log message *** (master branch start, has files) > Include stdfn.h. (adds just one file) > > In contrast cvs2git has the following first changesets: > > Initial import of beta340. (no files) > Import of beta 343. (has files) > This commit was manufactured by cvs2svn to create branch 'GNUPLOT_BETA'. > (has two files) > Import of beta 344. (all modifications) > Import of beta 345. (all modifications) > Import of beta 346. (all modifications) > Import of beta 347. (all modifications) > This commit was generated by cvs2svn to compensate for changes in r2, > which included commits to RCS files with non-trunk default branches. > (no files) > This commit was generated by cvs2svn to compensate for changes in r5, > which included commits to RCS files with non-trunk default branches. > (merge files into master branch) > Include stdfn.h. (adds just one file) > > The above cvs2git arrangement looks a lot like Eric's original > repository result, except that result was missing the merge back into > master branch. > > So, the ./reconvert file. I'm going to email Eric a diff file of the > changes I've made. > > 1) I've restored all the tags and branches, at least for the time being, > so that I could compare cvs-fast-export to cvs2git with greater detail. > Honestly, my preference would be to keep all tags, and I'd prefer that > HBB and Ethan (et al.) have a chance to see the full repository in a git > viewer first (I recommend qgit for this) before deciding to cut things > out. I like having the tags GNUPLOT_RELEASE_3_7_0, etc. and maybe > instead we could just add additional tags 3.7.0, etc. alongside the > original. > > HBB and Ethan should be able to run Eric's ./reconvert script to > generate the repository (it's just one command), so there's no need to > post any new repository to SourceForge. (And creating the cvs2git > version isn't too difficult either. Just use as an input to cvs2git the > gnuplot-cvs directory created by Eric's ./reconvert script.) > > 2) I used cvs2git's branch points in directives for reposurgeon. (Yes, > stuff like > > /Initial import of 3.6 beta340./ assign root37 > @min(/New file.$/),<root37> reparent --use-order --rebase > > (My learning curve was understanding various syntax in order to create > singletons.) > > > After having done the above, I find that tree-wise the two conversions > look similar, except for the first dozen changesets. cvs2git has more > logical file changes at the rebased branch point: the diffs look > correct, but I suspect the difference at the start of the repo result in > other files being swept in. > > Tag-wise, again very similar ("cvs2git created this branch for a tag", > etc. coincides well with "cvs-fast-export created this branch for a > tag"). However, I think cvs-fast-export is a little better at this at > the start of the repo than cvs2git. > > And exact file matches between the two conversions is difficult because > cvs2git drops all the RCSid strings. (We'll make sure all those things > are gone from the start of the new repo, which Eric may have already done.) > > > 3) I commented out the pre-CVS archival changesets for the time being. > I think we should just concentrate on that initial dozen changesets (try > to match cvs2git more, I couldn't figure out how to add merges via > reposurgeon), and if we get those cleared up my hope is that it works > its way through the whole tree and fixes up the branches without the > need of shims. > > Dan > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Eric S. R. <es...@th...> - 2017-10-29 21:14:45
|
sfeam <sf...@us...>: > On Sunday, 29 October 2017 14:01:15 Daniel J Sebald wrote: > > I've experimented with something called cvs2git, which I believe does a > > pretty good job of constructing branches and merges, but has some > > drawbacks. > > I think we are past the stage of looking for alternative conversion utilities. > > Can't we just flatten everything prior to version 4.0 into a baseline > snapshot that is the root for everything subsequent to that? We don't have to be quite that drastic. In particular, we can keep the archival releases you wanted glued to the tail without causing further difficulties. I do think we have readhed the point where it makes sense to just drop the 3.7.x branch and move forward. > I really don't see why anyone will ever need to modify or branch from > anything prior to 4.0. The tarballs are good enough for historical > reference. I just don't see why anyone would care about the branch > structure of 3.4/3.5/3.7/3.8 now that it's 20 years done and over. > > And if someone _does_ want the historical information for some reason > other than development going forward, they would do better to go back to > the archived cvs repository itself rather than having to deal with any > post-processing layers you might add now to make the cvs->git conversion > work. I concur. > I suggest that at this point the only issue worth spending more time > on is authorship attributions transferred from the ChangeLog series. > Once that is sorted out, let's call it a wrap. Well, filling in at least the wore recent empty log messages would be good too. But other than that, yes. -- <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-29 21:17:34
|
On 10/29/2017 03:34 PM, sfeam wrote: > On Sunday, 29 October 2017 14:01:15 Daniel J Sebald wrote: >> I've experimented with something called cvs2git, which I believe does a >> pretty good job of constructing branches and merges, but has some >> drawbacks. > > I think we are past the stage of looking for alternative conversion utilities. The point was something for comparison purposes and confirmation of the branch points for which cvs2git seems to match what I've been concluding, but others don't seem to trust. The reason for doing this is that we seem to be guessing at where things should go and how to devise shims to compensate. > Can't we just flatten everything prior to version 4.0 into a baseline > snapshot that is the root for everything subsequent to that? Spend time on that, or spend time to make that first dozen changesets in line with cvs2git. Whatever the case, we have to *start* from a point which is in agreement with the CVS repository so that the diffs going forward keep things in sync. > I really don't see why anyone will ever need to modify or branch from > anything prior to 4.0. The tarballs are good enough for historical > reference. I just don't see why anyone would care about the branch > structure of 3.4/3.5/3.7/3.8 now that it's 20 years done and over. I didn't suggest any effort to remove tags etc. Would have been fine with historical tags and whatever synthetic branches are added. What has mattered is recalling something from CVS and from the repository and have them match. Dan |
|
From: Eric S. R. <es...@th...> - 2017-10-29 21:41:21
|
Daniel J Sebald <dan...@ie...>: > I didn't suggest any effort to remove tags etc. Would have been fine with > historical tags and whatever synthetic branches are added. What has > mattered is recalling something from CVS and from the repository and have > them match. esr@snark:/mnt/vault/esr-vault/gnuplot-conversion$ checkbranches Master branch differences: Switched to branch 'master' 5-2 stable differences: Switched to branch 'branch-5-2-stable' 5-0 stable differences: Switched to branch 'branch-5-0-stable' 4-6 stable differences: Switched to branch 'branch-4-6-stable' 4-4 stable differences: Switched to branch 'branch-4-4-stable' 4-2 stable differences: Switched to branch 'branch-4-2-stable' 4-0 stable differences: Switched to branch 'branch-4-0-stable' /mnt/vault/esr-vault/gnuplot-conversion/gnuplot-git Switched to branch 'master' esr@snark:/mnt/vault/esr-vault/gnuplot-conversion$ For 4-0-stable and everything later we're there already. -- <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. |
