Re: New trial conversion

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

On 10/23/2017 04:24 PM, Ethan A Merritt via gnuplot-beta wrote:
> On Monday, October 23, 2017 1:46:25 PM PDT Hans-Bernhard Bröker wrote:
>> Am 23.10.2017 um 16:55 schrieb Eric S. Raymond:
>>> sfeam <sf...@us...>:
>>>> I don't understand the color scheme, but it cannot possibly be correct
>>>> to show either "branch52" or "b52right"  rooted in 4.0.2
>>>>
>>>> In fact 4.0.2 shouldn't be a branch at all.  It should be a tag
>>>> internal
>>>> to branch-4.0-stable.
>>>
>>> 4.0.2 is a tag (not a branch point), but it's a tag on the master
>>> branch. I have no explanation for this yet.
>>
>> The explanation for this is acually quite simple: 4.0.2 _is_ on the
>> trunk.
>>
>> 4.0 differs from later releases in that I didn't use parallel
>> "development" and "series" branches back then.  The tell-tale indication
>> can be found in the CVS tags of ChangeLog:
>>
>>           branch-4-0-stable: 1.1148.0.2
>>           GNUPLOT_RELEASE_4_0_2: 1.1147
>>           GNUPLOT_RELEASE_4_0_1: 1.1146
>>           GNUPLOT_RELEASE_4_0_0: 1.1086
>>
>> I.e. 4.0 patchlevel 0 to 2 were made directly on the trunk.  Only after
>> that was branch-4-0-stable started (but we never actually made another
>> release on that branch, so no further tags).
> 
> Ah. It all makes sense now.
> 
> So the ascii schematic that Eric showed is actually correct.
> The only other strangeness about it is that the
>   greenroot->...->3.7.1
> branch is printed near the top rather than near the bottom.
> 
> When I open today's version using gitg it doesn't show a
> 3.7 branch (or tag) at all.   I can live with that :-)
> 
> 	Ethan

It's not completely making sense here yet.

I see now how gitg is drawing its graph and arranging commits. 
Occasionally there are arrows that sort of mean "continued further down" 
rather than draw a line with no circles mean no commits.  So, if one 
follows, the first red line in gitg runs the length of the table/graph 
and is branch-5-0-stable having no commits.  I see there are several 
commits that appear in groups of two or three which are the same, i.e., 
Ethan must have made changes on the main branch and another branch at 
the same time.

I've just looked at the repository in qgit, and I see that it arranges 
the graph a bit differently.  It instead arranges commits by branch 
rather than chronological.  The result is something that looks more 
tree-like, and it's much more useful for the issue at hand at the 
moment.  I can then find the similar CVS checkins by "funnel search", 
for example:

master,  sanity check to trap `plot "+" binary`,  Ethan A 
Merritt<merritt@u.washington.edu>,  6/9/17 7:24 PM

branch-5-2-stable,  sanity check to trap `plot "+" binary`,  Ethan A 
Merritt<merritt@u.washington.edu>,  6/9/17 7:26 PM

branch-5-0-stable,  sanity check to trap `plot "+" binary`,  Ethan A 
Merritt<merritt@u.washington.edu>,  6/1/17 7:26 PM

NOTE THE DISCREPANCY in the date of the third example.  Is that some 
type of bug in the translation, i.e., that because the two times 7:26 PM 
are the same it is changing the date by 8 months?

Anyway, the big question for me is (looking at the qgit graph display, 
where this is obvious) why do (tag, but no branch name) 3.7.3, 
branch-4-0-stable, branch-4-2-stable, branch-4-4-stable, 
branch-4-6-stable, and branch-5-0-stable all spring from

Import of beta 347.
Author: Lars Hecking<xxxxx@xxxxx>
Author date: 6/23/98 9:11 AM
Parent: Import of beta 346.
Child: Start of separate branch for version 5 stable releases
Child: Bump stable version to 4.6; patchlevel is "alpha"
Child: Start branch for Release 4.4
Child: Jump to version 4.2, 1st release candidate.
Child: Bugfix: Incorrect brace movement cause lost key presses.
Child: Windows linestyle fix.
Branch: origin/branch-5-0-stable (update description of strlen to 
mention multibyte chars)
Branch: origin/branch-4-6-stable (vertical alignment of enhanced text 
fragments in cairo te...)
Branch: origin/branch-4-4-stable (protect command list execution with a 
mutex)
Branch: origin/branch-4-2-stable (boxwidth should not affect function 
plots unless the plot...)
origin/branch-4-0-stable (Removed mail address for privacy reasons.)
Branch: 3.5 (Content from gnuplot-3.5.tar.gz)
Branch: 5.0.0 (final), 4.6.0 (Release 4.6.0), 4.4.0 (Tag for 
Release_4_4_0), 4.2.1 (Tag 4.2.1), 3.7.1 (Updated.)

of the short branch springing from

Initial import of beta340.
Author: Lars Hecking<xxxxxx@xxxxxx>
Author: date 4/15/98 2:16 PM
Parent: Content from gnuplot-3.5.tar.gz
Child: *** empty log message ***
Child: Initial import of beta340.
Branch: master (Remove all RCS/CVS cookies.)
Branch: origin/master (Remove all RCS/CVS cookies.)
Branch: origin/branch-5-2-stable (Release 5.2.1)
Branch: origin/branch-5-0-stable (update description of strlen to 
mention multibyte chars)
Branch: origin/branch-4-6-stable (vertical alignment of enhanced text 
fragments in cairo te...)
Branch: origin/branch-4-4-stable (protect command list execution with a 
mutex)
Branch: origin/branch-4-2-stable (boxwidth should not affect function 
plots unless the plot...)
Branch: origin/branch-4-0-stable (Removed mail address for privacy 
reasons.)
Follows: 3.5 (Content from gnuplot-3.5.tar.gz)
Precedes: 4.0.2 (Massive change to all C sources:), 5.0.0 (final), 4.6.0 
(Release 4.6.0), 4.4.0 (Tag for Release_4_4_0), 4.2.1 (Tag 4.2.1), 3.7.1 
(Updated.)

??

It looks to me as though all these imports of "Initial import of 
beta340.", "Initial import of beta340." (listed a second time for some 
reason), "Import of beta 343.", "Import of beta 344.", "Import of beta 
345.", "Import of beta 346.", "Import of beta 347." correspond to the 
branches in some way, but for some reason these are all being tied back 
to the same date/time when perhaps they should be dispersed throughout 
the tree at times more in line with when those branches were created in 
CVS.  Is this a bug?  Is this the missing info that we need to make a 
guess at?

Dan


Dan