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

Re: New trial conversion

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

Daniel J Sebald <dan...@ie...>:
> On 10/23/2017 10:34 PM, Eric S. Raymond wrote:
> >Daniel J Sebald <dan...@ie...>:
> [snip]
> >The way to fix this kind of problem is to identify the original root points
> >for each branch and regraft them there. If you're very good and very lucky,
> >the rerooted branch's content at head will match what it was supposed to in
> >CVS and you won't have to throw it away.
> >
> >Odds that you can salvage a branch go up quadratically in how far back the
> >original root point.  I'm fairly confident about v5stable, more doubtful
> >about any of the others.

(I meant "go *down* quadratically".  Branches where te join point has moved
farther are harder to recover.)

> OK, I think I see now.  CVS treats individual files separately (not a
> snapshot of the whole file tree, as does git), so it is just a series of
> changes for individual files and whenever something is tagged, each file
> gets the tagged.  CVS doesn't really care where a branch took place, just
> the history of file changes (i.e., checkins).

That's correct.

Deducing a changeset structure from the individual file change histories
is *hard*, even when the metadata is all correct.

> So, if a file is renamed, the "searching-for-tags-regressively" rule is a
> bust because there may be a break in the continuity of the file as far as
> following back some branch to the main branch or any other branch it might
> have come from.

That's also correct.

> We aren't corrupting branches though, if I understand correctly, because it
> looks like reposurgeon just generates a big diff between the branches and
> "Import of beta 347".  (But I'm not sure how much faith I'd have in rebasing
> the git repo after the conversion.)  Basically, our goal is to minimize the
> diff-hunk distance between the start of a branch and some point along the
> main branch.  That should be very close to the original branch point.

Yes.

> Ethan, were all CVS branches originated from the main branch?  Or were some
> branches rooted from some non-main branch?

Ethan has answered this - 4.0 and onward were from trunk, before that unknown.
I can add that if we successfully reroot all those there will only be one other
branch left, the 3.7 one.

That one is strange.  It doesn't have the same root point as the others - in
fact the ascribed root point is right back at the beginning of the changeset
sequence.

> Of course, we can't search the whole history for the minimum diff-hunk
> distance between versions as that would take forever even by computer
> standards.  But we do have a pretty good initial guess based upon the dates
> of the first changeset in each branch.

Yes, that was my heuristic as well.

>                                 Let me write in the dates of the
> changeset alongside some of the info I posted last time:
> 
> Import of beta 347.
> Author: Lars Hecking<xxxxx@xxxxx>
> Author date: 6/23/98 9:11 AM
> Parent: Import of beta 346.
> [8/20/14 1:37 PM] Child: Start of separate branch for version 5 stable
> releases
> [11/21/11 11:26 PM] Child: Bump stable version to 4.6; patchlevel is "alpha"
> [5/30/09 7:30 PM] Child: Start branch for Release 4.4
> [10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
> [7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key
> presses.
> [1/14/99 8:13 AM] Child: Windows linestyle fix.
> 
> Looking at those dates, they all do seem to be about the correct year that
> such branches would have been made.
> 
> It sounds like you really don't want to dig into any code for this
> tag-regression code.  What info and what format would you need about the
> main branch so that you could force reposurgeon to accept the manual branch
> points?

I have everything I need.  This kind of branch surgery is one of the
operations reposurgeon was designed for.

> I would propose that we do the following for each of those branches above:
> 
> 1) Make side-by-side clones in different directories of the repository. (Or
> create side-by-side directories for CVS checkouts.)
> 
> 2) In one directory, checkout the version of the repository at the start of
> the branch, e.g., the changeset associated with "Windows linestyle fix.".
> 
> 3) In the second directory, checkout the version of the repository *master*
> branch +/-5 changesets from the date indicated with the changeset listed
> above, e.g., 1/14/99 8:13 AM.
> 
> 4) For each of those checkouts, somehow use the OS diff tool in a
> directory-vs-directory comparison to measure the number of differences,
> i.e., the distance between the two source trees for the given versions.
> 
> 5) Choose as the branch point the version in master branch that has the
> minimum distance.
> 
> Does that seem like a reasonable plan?

It's not only reasonable, it's very close to mine.   Main difference is that
in at leasrt one case (v5stable) we already know what the right branch point
is.

>                                      Is it just those six branches that
> I've listed, or are there more?

That's it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

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

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

Daniel J Sebald <dan...@ie...>:
> I've enhanced my utility with the following subtle change:  search for first
> item (i.e., line has a star * or colon :) within the addition diff hunk.
> This corrected 4 entries, which I've listed on SourceForge here:
> 
> https://sourceforge.net/p/gnuplot/patches/763/#5709

My code picks up all four of these cases.

I believe the ChangeLog-parsing algorithm parsing is now good enough.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: New trial conversion

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

sfeam <sf...@us...>:
> So far as I know all branches starting with 4.0 split from the main trunk.
> (Although see Hans-Bernhard's clarification that 4.0.0, 4.0.1 and 4.0.2
> were tagged directly in the main trunk before a separate branch-4.0-stable
> was created).
> 
> I think Lars Hecking is probably the only one with any hope of remembering 
> exactly how the version 3.X pieces were handled when they were 
> merged to create the SourceForge repository.   I gather from the comments
> in the early commits that there were multiple "branches" (maybe not
> in the cvs sense but variant sources maintained by different people) that
> were merged to set up the repository on SourceForge in 1999(?).
> After that it looks like all development happened in a single (main) branch
> delineated only by TAGs until the current system of one branch per
> stable series was adopted just a little too late to catch the start of
> 4.0-stable

Thanks, that is illuminating.

I'm ready to start working on the branch grafting now.

For each branch, I'm going to try to identify the correct root point and
move it there.  Correctness will be checked by diffing a checkout of the
rerooted branch tip against a CVS checkout of the same tag.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: New trial conversion

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

On Tuesday, 24 October 2017 00:03:51 Daniel J Sebald wrote:
> Ethan, were all CVS branches originated from the main branch?  Or were 
> some branches rooted from some non-main branch?

So far as I know all branches starting with 4.0 split from the main trunk.
(Although see Hans-Bernhard's clarification that 4.0.0, 4.0.1 and 4.0.2
were tagged directly in the main trunk before a separate branch-4.0-stable
was created).

I think Lars Hecking is probably the only one with any hope of remembering 
exactly how the version 3.X pieces were handled when they were 
merged to create the SourceForge repository.   I gather from the comments
in the early commits that there were multiple "branches" (maybe not
in the cvs sense but variant sources maintained by different people) that
were merged to set up the repository on SourceForge in 1999(?).
After that it looks like all development happened in a single (main) branch
delineated only by TAGs until the current system of one branch per
stable series was adopted just a little too late to catch the start of
4.0-stable

	Ethan  

Re: New trial conversion

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

On 10/23/2017 10:34 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
[snip]
> The way to fix this kind of problem is to identify the original root points
> for each branch and regraft them there. If you're very good and very lucky,
> the rerooted branch's content at head will match what it was supposed to in
> CVS and you won't have to throw it away.
> 
> Odds that you can salvage a branch go up quadratically in how far back the
> original root point.  I'm fairly confident about v5stable, more doubtful
> about any of the others.

OK, I think I see now.  CVS treats individual files separately (not a 
snapshot of the whole file tree, as does git), so it is just a series of 
changes for individual files and whenever something is tagged, each file 
gets the tagged.  CVS doesn't really care where a branch took place, 
just the history of file changes (i.e., checkins).

So, if a file is renamed, the "searching-for-tags-regressively" rule is 
a bust because there may be a break in the continuity of the file as far 
as following back some branch to the main branch or any other branch it 
might have come from.

We aren't corrupting branches though, if I understand correctly, because 
it looks like reposurgeon just generates a big diff between the branches 
and "Import of beta 347".  (But I'm not sure how much faith I'd have in 
rebasing the git repo after the conversion.)  Basically, our goal is to 
minimize the diff-hunk distance between the start of a branch and some 
point along the main branch.  That should be very close to the original 
branch point.

Ethan, were all CVS branches originated from the main branch?  Or were 
some branches rooted from some non-main branch?

Of course, we can't search the whole history for the minimum diff-hunk 
distance between versions as that would take forever even by computer 
standards.  But we do have a pretty good initial guess based upon the 
dates of the first changeset in each branch.  Let me write in the dates 
of the changeset alongside some of the info I posted last time:

Import of beta 347.
Author: Lars Hecking<xxxxx@xxxxx>
Author date: 6/23/98 9:11 AM
Parent: Import of beta 346.
[8/20/14 1:37 PM] Child: Start of separate branch for version 5 stable 
releases
[11/21/11 11:26 PM] Child: Bump stable version to 4.6; patchlevel is "alpha"
[5/30/09 7:30 PM] Child: Start branch for Release 4.4
[10/1/06 10:17 AM] Child: Jump to version 4.2, 1st release candidate.
[7/7/04 12:34 PM] Child: Bugfix: Incorrect brace movement cause lost key 
presses.
[1/14/99 8:13 AM] Child: Windows linestyle fix.

Looking at those dates, they all do seem to be about the correct year 
that such branches would have been made.

It sounds like you really don't want to dig into any code for this 
tag-regression code.  What info and what format would you need about the 
main branch so that you could force reposurgeon to accept the manual 
branch points?

I would propose that we do the following for each of those branches above:

1) Make side-by-side clones in different directories of the repository. 
(Or create side-by-side directories for CVS checkouts.)

2) In one directory, checkout the version of the repository at the start 
of the branch, e.g., the changeset associated with "Windows linestyle fix.".

3) In the second directory, checkout the version of the repository 
*master* branch +/-5 changesets from the date indicated with the 
changeset listed above, e.g., 1/14/99 8:13 AM.

4) For each of those checkouts, somehow use the OS diff tool in a 
directory-vs-directory comparison to measure the number of differences, 
i.e., the distance between the two source trees for the given versions.

5) Choose as the branch point the version in master branch that has the 
minimum distance.

Does that seem like a reasonable plan?  Is it just those six branches 
that I've listed, or are there more?

Dan

Re: New trial conversion

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

Daniel J Sebald <dan...@ie...>:
> 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
> ??
> 
> 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?

I tried to explain this before.  It's so confusing that I don't blame anyone
for having missed or misunderstood the explanation.

The way CVS does tags is by propagating an instance of the tag to every
master in the repository.  One *kind* of tag designates the root node
of a branch.  When all goes well, these sets of tags begin - and remain
- complete. That is, every master is tagged.

Sometimes, due to one of CVS's ninety-kajillion bugs - or perhaps due to
a quantum fluctuation in some Schrodinger's box somewhere - a tag set is
created incompletely, or a complete tag loses one of its marbles.  This
especially likely if you do dangerous things to the repository. Dangerous
things include deleting or - worse - attempting to rename files.

Incomplete tag sets are like bombs waiting to go off.  If you do nothing but
checkouts at branch heads, you may never notice they're broken - though the
consequences can include incomplete checkouts at tags, and *projects have
been sunk this way*.

Now you run cvs-fast-export on your repo.  It's trying to deduce a
changeset graph. It really, really wants to only deal with complete
tag sets.  (Because incomplete tags sets are dangerous: see, incomplete
checkouts.)  The worst case, which we have struck here, is that the
tag identifying a branch root node is incomplete.

It is kind of murky what happens next; there is not anyone, including me,
who completely understands the core code in cvs-fast-export.  The person
who wrote it, Keith Packard (the X guy) has forgotten.

What seems to happen is that the code starts replicating changesets at the
base of the branch, moving the join point backward until it can identify a
common ancestor node that has a complete tag set.  Often this is quite far
back.

This crazy graph:

redroot ---> redleft -> 4.0.2 -> branch52 --> b52left ---> master
   |                                |
   |                                +-------> b52right --> 5.2.0 --> 5.2.1
   +-------> redright -+
                       |
+----------------------+
|
+-> greenroot ---> greenright ---> 3.7.1 --> 3.7.2  --> 3.7.3
        |
        |
+-------+
|
+-> v5stable -> 5.0.[01234567] -> branch-5.0-stable
|
+-> bump46 -> 4.6.[0123456] -> branch 4.6-stable
|
+-> start44 -> 4.4.[01] -> 4.4.[34] -> branch-4.4-stable
|
+-> jump42 -> 4.2.[123456] -> branch-4.2-stable
|
+-> greenbug -> branch-4.0-stable

is a result of several waves of branches getting rooted *way* further back
in the tree than they ought to because there was only an incomplete branch root
tag where the actual branch should have been.

Or something like that. The failure nodes from damaged CVS metadata are so
%$^#% complicated and obscure that even I, who am the world's &#$@$#@! expert
on this problem, don't completely understand them.  Seriously.  It's a minor
miracle that CVS works at all, and a major miracle that cvs-fast-export does.

The way to fix this kind of problem is to identify the original root points
for each branch and regraft them there. If you're very good and very lucky,
the rerooted branch's content at head will match what it was supposed to in
CVS and you won't have to throw it away.

Odds that you can salvage a branch go up quadratically in how far back the
original root point.  I'm fairly confident about v5stable, more doubtful
about any of the others.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: AW: New trial conversion

[Mojca M. <moj...@gm...>]

23. okt. 2017 3:03 PM "Eric S. Raymond":

Mojca Miklavec <moj...@gm...>:
> No, the reason was probably that there were too many "junk tags". I can
> push other tags if that helps in any way.

Which tags can you identify?  We'll probably want to patch them into the
conversion.


Just useless tags discussed a few days ago. Nothing useful to look into.

Mojca

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

Re: New trial conversion

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

Hans-Bernhard Bröker <HBB...@t-...>:
> 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).

That is good to know!  Thanks.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: AW: New trial conversion

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

Mojca Miklavec <moj...@gm...>:
> No, the reason was probably that there were too many "junk tags". I can
> push other tags if that helps in any way.

Which tags can you identify?  We'll probably want to patch them into the
conversion.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: New trial conversion

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

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

Re: New trial conversion

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

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).

Re: AW: New trial conversion

[Mojca M. <moj...@gm...>]

23. okt. 2017 11:45 AM "Bastian Märkisch" wrote:

> The ugly part is that all the other branch joins are in obviously wrong
places.
> I will need to identify graft points for the other branches and move them.
>

FWIW, from a quick inspection using gitk at least the stable branches back
to 4.0 look correct in Mojca's repository on github:
https://github.com/gnuplot/gnuplot.git
But then again she earlier pointed out that she stopped doing tags after
4.6.0 because of problems.


No, the reason was probably that there were too many "junk tags". I can
push other tags if that helps in any way.

Mojca

AW: New spin of repository conversion

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

> > > Can you be more specific about the time this happened, and in what
> > > way the git conversion fails to reflect the old history?
> > >
> >
> > If you look at
> > http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/?hideattic=0
> > &pathr
> > ev=MAIN
> > there are a number of files marked "dead" deleted by Lars Hecking with
> > a commit comment "Moved to ..." Similarily for /NeXT/, /beos/, /win/,
> > /os2/.  I was wondering if the history of these files could be
> > prepended (again) to the history of the destination files. That is if
> > that is easy enough.  That part of the history was "lost"
> > some 18y ago ;)
> 
> This probably didn't lose any history at all.  If these were moved back to
their
> original locations later, then both moves will be part of the gitspace
history.
> 

It is "lost" because the moved files and the deletes were committed in
subsequent commits. So git cannot interpret that as a "move" operation.
That happened in a sequence committed by Lars Hecking on 1999-03-26 at
22:32:57 - 23:19:32 (11 commits labelled "Moved from <dirold>." or "Moved to
<dirnew>."). 
Any chance of "merging" these commits?  (But the other issues are way more
important).

  Bastian


> Frankly, if this has gone wrong, I'd be very nervous about trying to fix
it.  CVS is
> flaky enough even when used as intended; moving around or otherwise
> messing with master files behind CVS's back tends to make very bad things
> happen.

AW: New trial conversion

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

> The ugly part is that all the other branch joins are in obviously wrong
places.
> I will need to identify graft points for the other branches and move them.
> 

FWIW, from a quick inspection using gitk at least the stable branches back
to 4.0 look correct in Mojca's repository on github:
https://github.com/gnuplot/gnuplot.git
But then again she earlier pointed out that she stopped doing tags after
4.6.0 because of problems.

I have uploaded graphical representations of the trees of both repos done
with TortoiseGit to
https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

  Bastian

Re: New trial conversion

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

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.

> > Allowing for EDT time-zone shift it looks like the v5stable commit to
> > start the branch took place about 50 minutes before 5.1 was marked,
> > so if we transplant v5stable to be a child of /Empirical adjustments
> > to dashlength/ and then nuke the older commits on the branch, that should
> > restore the original topology.
> > 
> > Ethan, can you confirm that this fork point is correct?
> 
> The timing is correct.
> The "empirical adjustments" thingy is the last common ancestral node
> to branch-5.0-stable and the current main branch
> 
> But I definitely do not understand what operation you are proposing to
> perform :-)

I'm going to move the v5stable branch to be based on /empirical adjustments/,
restoring correct topology.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: New trial conversion

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

Daniel J Sebald <dan...@ie...>:
> On 10/22/2017 11:03 PM, Eric S. Raymond wrote:
> >This one is 58ab3388946d9312812c276fa31cc464a617b304
> 
> There is a warning at the end that I don't recall in previous versions:

Well, that was weird. I tried re-pushing it, failed a couple of times,
then discovered that in my procedure for nuking and reinitializing
the upstream repo, it really matters that you have to say "git init --bare .",
if you leave off the last dot the command will appear to succeed but
make a repo that can't be pushed to.

All fixed now. You should be able to clone with

git clone ssh://esr@git.code.sf.net/p/gnuplot/git-main gnuplot-git-main

and not get that error. I just did.

For the record, here's how you clobber a SourceForge git repo:

ssh -t es...@sh... create

You would have to substitute your own account ID for 'esr'. This
command will give you access to a special-purpose restricted shell.
Once in it,

cd /home/git/p/gnuplot

You should see a directory there named git-main.git.  This is the git repo.
Do this to clobber it:

cd git-main.git
rm -fr *
git init --bare .

After this sequence,

git push --force --mirror

from within your local conversion will work, pushing all its branches
and tags to SourceForge

> I'm guessing, from the graph generated by gitg, that master should coincide
> with tag "git-conversion" as it currently stands.

Correct.

> It looks to me, in gitg, that branch52 is coming from what would be
> considered "master".

Also correct.

The ugly part is that all the other branch joins are in obviously wrong places.
I will need to identify graft points for the other branches and move them.

Then I'll have to check that each regrafted branch checks out to the
same working tree as the CVS original. I'm worried about this part
because the root tags were so corrupted; worst case we may not be able
to save any branches other than master and 5.2.

> These graphs are such a difficult thing to following in something like gitk
> or gitg, and it's because those tools aren't really geared for nice display
> of branching.  If I select one of the tags in gitg, the graph jumps there
> but it only displays commits up to that tag.  It doesn't put in context with
> all other branches.

Alas, this is so.  Getting a usable visualization of the essential
structure of a repo is something I don't know how to do.  reposurgeon
has a graph command that fenerates a DOT visualization, but for any
real repo the diagram is infeasibly huge.

> I've tried using cvsgraph to generate a graph of where the CVS branches
> occur, but no luck.

I didn't know this tool existed. Unfortunately it looks both complicated to
use and subject to the same problem as my graph command.

> >We're going to have to do 4 or 5 similar grafts to restore the tree to
> >correct topology.
> 
> Is it possible to rebase some things after conversion to correct that paths?

Yes, but just as easy to do the equivalent of the rebase in the
conversion script.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: New trial conversion

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

On 10/22/2017 11:03 PM, Eric S. Raymond wrote:
> This one is 58ab3388946d9312812c276fa31cc464a617b304

There is a warning at the end that I don't recall in previous versions:

sebald@ ~/gnuplot/test_repository/fifth_sourceforge $ git clone 
https://git.code.sf.net/p/gnuplot/git-main
Cloning into 'git-main'...
remote: Counting objects: 77463, done.
remote: Compressing objects: 100% (14325/14325), done.
remote: Total 77463 (delta 63011), reused 77463 (delta 63011)
Receiving objects: 100% (77463/77463), 20.76 MiB | 590.00 KiB/s, done.
Resolving deltas: 100% (63011/63011), done.
Checking connectivity... done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

When I then open gitk, I see the error message

"Error parsing revisions: unknown revision HEAD"

in a dialog box.  After selecting OK, gitk shows "No commits selected".

Here is what's missing from .git/config compared to a previous conversion:

sebald@ ~/gnuplot/test_repository/fifth_sourceforge/git-main $ diff -u 
../../fourth_sourceforge/git-main/.git/config .git/config
--- ../../fourth_sourceforge/git-main/.git/config	2017-10-20 
17:01:08.244831322 -0500
+++ .git/config	2017-10-22 23:52:56.825037433 -0500
@@ -6,8 +6,3 @@
  [remote "origin"]
  	url = https://git.code.sf.net/p/gnuplot/git-main
  	fetch = +refs/heads/*:refs/remotes/origin/*
-[branch "master"]
-	remote = origin
-	merge = refs/heads/master
-[gitg]
-	mainline = refs/heads/master

I'm guessing, from the graph generated by gitg, that master should 
coincide with tag "git-conversion" as it currently stands.


With gitg, selecting a lot of the tags does not produce a graph:

Tag
---
Up to branch 3.5 produces a graph
3.7.1 through 3.7.3 no graph
4.0.2 produces a graph
4.2.1 through 4.6.2 no graph
4.6.3 produces a graph
4.6.4 through 5.2.1 no graph

The previous revision behaves the same way.


> The longlines corrections are mostly back in.
> 
> I stuck with author-based action stamps, but the rule for filling in
> time of day on a ChangeLog attribution is now much simpler:
> 
>      Due to the limitations of the ChangeLog format, attribution dates on
>      these author records will be set to have the hh:mm:ss part of the
>      committer date and the committer's timezone; then various tricks are
>      tried to correct the timezone, including looking in the author map if
>      there is one. This choice is often close to right (e.g if the
>      committer is the author) and no worse than any other arbitrary
>      assignment would be.
> 
> This should greatly reduce action-stamp collisions, as two
> attributions have only a 1/360th chance of having the same mm:ss
> part.
> 
> There's a more serious issue.
> 
> I've looked at the repo topology in detail and it turns out to be
> rather a mess. Key locations in the repo are as follows.
> 
> redroot    1998-04-15 15:16:47  /Initial import of beta340./
> redright   1998-04-15 15:16:52  /Initial import of beta340./
> redleft    1998-04-15 15:21:47  /*** empty log message ***/
> branch52   2017-05-22 01:05:26  /Tag branchpoint for 5.2;/
> b52left    2017-05-21 08:00:02  /bump versioning to 5.2.rc0/
> b52right   2017-05-22 01:16:28  /Note policy for new patches applied/
> greenroot  1998-06-23 10:11:50  /Import of beta 347./
> greenright 1999-01-14 07:00:00  /Windows linestyle fix./
> v5stable   2014-08-20 08:00:01  /Start of separate branch for version 5 stable/
> bump46     2011-11-22 07:00:07  /Bump stable version to 4.6;/
> start44    2009-05-31 08:00:07  /Start branch for Release 4.4
> jump42     2006-10-01 08:00:05  /Jump to version 4.2, 1st release candidate./
> greenbug   2004-07-07 08:00:01  /Bugfix: Incorrect brace movement/
> 
> The directions 'right' and 'left', and the colors, describe the way
> the graph looks under gitk (colors aren't stable, though).  Here is a
> graph of the branchpoints:
> 
> redroot ---> redleft -> 4.0.2 -> branch52 --> b52left ---> master
>     |                                |
>     |                                +-------> b52right --> 5.2.0 --> 5.2.1
>     +-------> redright -+
>                         |
> +----------------------+
> |
> +-> greenroot ---> greenright ---> 3.7.1 --> 3.7.2  --> 3.7.3
>          |
>          |
> +-------+
> |
> +-> v5stable -> 5.0.[01234567] -> branch-5.0-stable
> |
> +-> bump46 -> 4.6.[0123456] -> branch 4.6-stable
> |
> +-> start44 -> 4.4.[01] -> 4.4.[34] -> branch-4.4-stable
> |
> +-> jump42 -> 4.2.[123456] -> branch-4.2-stable
> |
> +-> greenbug -> branch-4.0-stable
> 
> This is pretty badly wrong.  In fact of the three branch points - redroot,
> greenroot, and branch52 - only branch52 is correct.

It looks to me, in gitg, that branch52 is coming from what would be 
considered "master".

These graphs are such a difficult thing to following in something like 
gitk or gitg, and it's because those tools aren't really geared for nice 
display of branching.  If I select one of the tags in gitg, the graph 
jumps there but it only displays commits up to that tag.  It doesn't put 
in context with all other branches.

I've tried using cvsgraph to generate a graph of where the CVS branches 
occur, but no luck.


> This kind of failure happens in cvs-fast-export as a fallback when it
> encounters incomplete root tags (CVS tags associated with a branch
> root).  I don't completely understand the recovery logic - I didn't
> write it, and the person who did has let the details slip.  What it
> tries to do (I think) is run the join point backward from the
> incomplete root tag until it find something it can recognize as an
> ancestor, duplicating as many common changesets as it needs to to reroot
> the branch.
> 
> To rectify this for each branch, we need to locate the correct branch
> point, the place where the bad root tag happened, and perform a graft.
> Looking at the v5stable commit date of 2014-08-20 14:37:30 we find
> these omn the master branch.
> 
> 42617 2014-08-20T12:00:00Z Empirical adjustments to dashlength calculated a
> 42619 2014-08-20T19:32:14Z Mark as 5.1
> 
> Allowing for EDT time-zone shift it looks like the v5stable commit to
> start the branch took place about 50 minutes before 5.1 was marked,
> so if we transplant v5stable to be a child of /Empirical adjustments
> to dashlength/ and then nuke the older commits on the branch, that should
> restore the original topology.
> 
> Ethan, can you confirm that this fork point is correct?
> 
> We're going to have to do 4 or 5 similar grafts to restore the tree to
> correct topology.

Is it possible to rebase some things after conversion to correct that paths?

Dan

Re: New trial conversion

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

On Monday, 23 October 2017 00:03:37 Eric S. Raymond wrote:
> This one is 58ab3388946d9312812c276fa31cc464a617b304
> 
> The longlines corrections are mostly back in.
> 
> I stuck with author-based action stamps, but the rule for filling in
> time of day on a ChangeLog attribution is now much simpler:
> 
>     Due to the limitations of the ChangeLog format, attribution dates on
>     these author records will be set to have the hh:mm:ss part of the
>     committer date and the committer's timezone; then various tricks are
>     tried to correct the timezone, including looking in the author map if
>     there is one. This choice is often close to right (e.g if the
>     committer is the author) and no worse than any other arbitrary
>     assignment would be.
> 
> This should greatly reduce action-stamp collisions, as two
> attributions have only a 1/360th chance of having the same mm:ss
> part.
> 
> There's a more serious issue.
> 
> I've looked at the repo topology in detail and it turns out to be
> rather a mess. Key locations in the repo are as follows.
> 
> redroot    1998-04-15 15:16:47  /Initial import of beta340./
> redright   1998-04-15 15:16:52  /Initial import of beta340./
> redleft    1998-04-15 15:21:47  /*** empty log message ***/
> branch52   2017-05-22 01:05:26  /Tag branchpoint for 5.2;/
> b52left    2017-05-21 08:00:02  /bump versioning to 5.2.rc0/
> b52right   2017-05-22 01:16:28  /Note policy for new patches applied/
> greenroot  1998-06-23 10:11:50  /Import of beta 347./
> greenright 1999-01-14 07:00:00  /Windows linestyle fix./
> v5stable   2014-08-20 08:00:01  /Start of separate branch for version 5 stable/
> bump46     2011-11-22 07:00:07  /Bump stable version to 4.6;/
> start44    2009-05-31 08:00:07  /Start branch for Release 4.4
> jump42     2006-10-01 08:00:05  /Jump to version 4.2, 1st release candidate./
> greenbug   2004-07-07 08:00:01  /Bugfix: Incorrect brace movement/
> 
> The directions 'right' and 'left', and the colors, describe the way
> the graph looks under gitk (colors aren't stable, though).  Here is a
> graph of the branchpoints:
> 
> redroot ---> redleft -> 4.0.2 -> branch52 --> b52left ---> master
>    |                                |
>    |                                +-------> b52right --> 5.2.0 --> 5.2.1
>    +-------> redright -+
>                        |
> +----------------------+
> |
> +-> greenroot ---> greenright ---> 3.7.1 --> 3.7.2  --> 3.7.3
>         |
>         |
> +-------+
> |
> +-> v5stable -> 5.0.[01234567] -> branch-5.0-stable
> |
> +-> bump46 -> 4.6.[0123456] -> branch 4.6-stable
> |
> +-> start44 -> 4.4.[01] -> 4.4.[34] -> branch-4.4-stable
> |
> +-> jump42 -> 4.2.[123456] -> branch-4.2-stable
> |
> +-> greenbug -> branch-4.0-stable
> 
> This is pretty badly wrong.  In fact of the three branch points - redroot,
> greenroot, and branch52 - only branch52 is correct.

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.


> 
> This kind of failure happens in cvs-fast-export as a fallback when it
> encounters incomplete root tags (CVS tags associated with a branch
> root).  I don't completely understand the recovery logic - I didn't
> write it, and the person who did has let the details slip.  What it
> tries to do (I think) is run the join point backward from the
> incomplete root tag until it find something it can recognize as an
> ancestor, duplicating as many common changesets as it needs to to reroot
> the branch.
> 
> To rectify this for each branch, we need to locate the correct branch
> point, the place where the bad root tag happened, and perform a graft.
> Looking at the v5stable commit date of 2014-08-20 14:37:30 we find
> these omn the master branch.
> 
> 42617 2014-08-20T12:00:00Z Empirical adjustments to dashlength calculated a
> 42619 2014-08-20T19:32:14Z Mark as 5.1
> 
> Allowing for EDT time-zone shift it looks like the v5stable commit to
> start the branch took place about 50 minutes before 5.1 was marked,
> so if we transplant v5stable to be a child of /Empirical adjustments
> to dashlength/ and then nuke the older commits on the branch, that should
> restore the original topology.
> 
> Ethan, can you confirm that this fork point is correct?

The timing is correct.
The "empirical adjustments" thingy is the last common ancestral node
to branch-5.0-stable and the current main branch

But I definitely do not understand what operation you are proposing to
perform :-)

To the extent I follow the ascii art diagram above, it looks to me that
everything is OK except for  
  - greenroot should be below greenbug
  - 4.0.2 should not exist.

 
> We're going to have to do 4 or 5 similar grafts to restore the tree to
> correct topology.

not sure I have shed any light on it 
I can try again if you can rephrase the question

	Ethan

New trial conversion

[<es...@th...>]

This one is 58ab3388946d9312812c276fa31cc464a617b304

The longlines corrections are mostly back in.

I stuck with author-based action stamps, but the rule for filling in
time of day on a ChangeLog attribution is now much simpler:

    Due to the limitations of the ChangeLog format, attribution dates on
    these author records will be set to have the hh:mm:ss part of the
    committer date and the committer's timezone; then various tricks are
    tried to correct the timezone, including looking in the author map if
    there is one. This choice is often close to right (e.g if the
    committer is the author) and no worse than any other arbitrary
    assignment would be.

This should greatly reduce action-stamp collisions, as two
attributions have only a 1/360th chance of having the same mm:ss
part.

There's a more serious issue.

I've looked at the repo topology in detail and it turns out to be
rather a mess. Key locations in the repo are as follows.

redroot    1998-04-15 15:16:47  /Initial import of beta340./
redright   1998-04-15 15:16:52  /Initial import of beta340./
redleft    1998-04-15 15:21:47  /*** empty log message ***/
branch52   2017-05-22 01:05:26  /Tag branchpoint for 5.2;/
b52left    2017-05-21 08:00:02  /bump versioning to 5.2.rc0/
b52right   2017-05-22 01:16:28  /Note policy for new patches applied/
greenroot  1998-06-23 10:11:50  /Import of beta 347./
greenright 1999-01-14 07:00:00  /Windows linestyle fix./
v5stable   2014-08-20 08:00:01  /Start of separate branch for version 5 stable/
bump46     2011-11-22 07:00:07  /Bump stable version to 4.6;/
start44    2009-05-31 08:00:07  /Start branch for Release 4.4
jump42     2006-10-01 08:00:05  /Jump to version 4.2, 1st release candidate./
greenbug   2004-07-07 08:00:01  /Bugfix: Incorrect brace movement/

The directions 'right' and 'left', and the colors, describe the way
the graph looks under gitk (colors aren't stable, though).  Here is a
graph of the branchpoints:

redroot ---> redleft -> 4.0.2 -> branch52 --> b52left ---> master
   |                                |
   |                                +-------> b52right --> 5.2.0 --> 5.2.1
   +-------> redright -+
                       |
+----------------------+
|
+-> greenroot ---> greenright ---> 3.7.1 --> 3.7.2  --> 3.7.3
        |
        |
+-------+
|
+-> v5stable -> 5.0.[01234567] -> branch-5.0-stable
|
+-> bump46 -> 4.6.[0123456] -> branch 4.6-stable
|
+-> start44 -> 4.4.[01] -> 4.4.[34] -> branch-4.4-stable
|
+-> jump42 -> 4.2.[123456] -> branch-4.2-stable
|
+-> greenbug -> branch-4.0-stable

This is pretty badly wrong.  In fact of the three branch points - redroot,
greenroot, and branch52 - only branch52 is correct.

This kind of failure happens in cvs-fast-export as a fallback when it
encounters incomplete root tags (CVS tags associated with a branch
root).  I don't completely understand the recovery logic - I didn't
write it, and the person who did has let the details slip.  What it
tries to do (I think) is run the join point backward from the
incomplete root tag until it find something it can recognize as an
ancestor, duplicating as many common changesets as it needs to to reroot
the branch.

To rectify this for each branch, we need to locate the correct branch
point, the place where the bad root tag happened, and perform a graft.
Looking at the v5stable commit date of 2014-08-20 14:37:30 we find
these omn the master branch.

42617 2014-08-20T12:00:00Z Empirical adjustments to dashlength calculated a
42619 2014-08-20T19:32:14Z Mark as 5.1

Allowing for EDT time-zone shift it looks like the v5stable commit to
start the branch took place about 50 minutes before 5.1 was marked,
so if we transplant v5stable to be a child of /Empirical adjustments
to dashlength/ and then nuke the older commits on the branch, that should
restore the original topology.

Ethan, can you confirm that this fork point is correct?

We're going to have to do 4 or 5 similar grafts to restore the tree to
correct topology.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

The most foolish mistake we could possibly make would be to permit 
the conquered Eastern peoples to have arms.  History teaches that all 
conquerors who have allowed their subject races to carry arms have 
prepared their own downfall by doing so.
        -- Adolph Hitler, April 11 1942.

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

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

On 10/21/2017 03:53 PM, Daniel J Sebald wrote:
> On 10/21/2017 03:31 PM, "Bastian Märkisch" wrote:
>>> Gesendet: Samstag, 21. Oktober 2017 um 22:08 Uhr
>>> Betreff: Re: Aw: Re: News spin of repository conversion
>>>
>>> On 10/21/2017 02:53 PM, "Bastian Märkisch" wrote:
[snip]
> I can easily address that in the utility by starting not from the first 
> '+' change, but from the last '+' change of the first block of '+' 
> changes.  However, I'm not sure that can be done with Eric's python 
> algorithm because one needs to differentiate between the addition '+', 
> subtraction '-'.  The python approach only differentiates between 
> modified line ('+' or '-') and non-modified line (' ').  The '+' and '-' 
> come from the diff utility, which is surprisingly sophisticated.

I've enhanced my utility with the following subtle change:  search for 
first item (i.e., line has a star * or colon :) within the addition diff 
hunk.  This corrected 4 entries, which I've listed on SourceForge here:

https://sourceforge.net/p/gnuplot/patches/763/#5709

Here's an example of those 4 in which the first added line is a space 
and the author info appears in the second changed line, not the first:

@@ -1,50 +1,58 @@
+
+2000-09-20  Jjjjjj Zzzzzz <xxxxxx@xxxxxx>
+
+   * relative arrows:

So, the new algorithm will search until finding the * of "  * relative 
arrows:" (line 4).  Then searching backward from that point (line 4) 
will find the proper author (line 2).

Dan

Re: Aw: Re: News spin of repository conversion

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

On Saturday, 21 October 2017 18:11:06 Daniel J Sebald wrote:
> Ethan, et al.  Would you be fine with the committer time and author time 
> always being the same?  The ChangeLog entry date probably isn't real 
> accurate in itself, is it?

The ChangeLog dates as written are only guaranteed to be monotonic, 
not individually accurate.   I don't always recall today's date correctly,
and anyhow if Bastian or Hans-Bernhard  (both up to 10 hrs ahead of me)
has  already made a ChangeLog entry for, say, 5 November, I'll mark my
change as 5 November also even though it's still the 4th in Seattle. 
That way the ChangeLog dates remain monotonic.

Maybe there's a better system, but that's what I've been doing.

	Ethan

Re: Aw: Re: News spin of repository conversion

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

Daniel J Sebald <dan...@ie...>:
> Oh, you are trying to add Author information that coincides with the
> ChangeLog date.  I was just thinking that CVS doesn't have an Author and
> Committer date/time so whatever the CVS checkin time is becomes both those
> date/times in git.
> 
> If the date/time is the same, just add an hour (or tick), but of course if
> there are more than two such date/times then one has to be careful to
> continue checking.  That is, we can't do
> 
> Assume:
> dt25 == dt26 == dt27
> 
> First comparison:
> dt25 == dt26  >  dt26++
> 
> Second comparison:
> dt25 == dt27  >  dt27++
> 
> because then dt26 and dt27 end up equal.
> 
> Is there a situation if the commit time on a given day is 9:00 am and the
> assigned author date is the same day 12:00 pm that the author date/time ends
> up ahead of committer date/time?  That would be odd.

It's worse than you know.  ChangeLog date stamps don't have a timezone.
They are, presumably, in the local TZ of the author, but we don't know what
that is.

All of this has me about persuaded to switch action stamps to being based
on commit times, which we always know to the second.  I liked the author-
based semantics better, but action stamps from imprecise dates creates
too many collisions and special-case rules. 

> Ethan, et al.  Would you be fine with the committer time and author time
> always being the same?  The ChangeLog entry date probably isn't real
> accurate in itself, is it?

*I* don't think this is a good idea.  Throws away information that
might be interesting.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

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

Re: Aw: Re: News spin of repository conversion

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

On 10/21/2017 05:41 PM, Eric S. Raymond wrote:
> Daniel J Sebald <dan...@ie...>:
>> However, I don't understand the requirement that the date be unique. The
>> only changes to be made for the changeset are Author and Email.  The more
>> detailed information about the SHA, commiter, etc. remains the same.  Why
>> the requirement?
> 
> It's so each commit can be identified by a unique action stamp based
> on its author address and authorship time.  Otherwise it's difficult
> for reposurgeon to have a unique way to refer to commits, which makes
> it difficult to write surgical commands.
> 
> Why the athor date and not the committer date, which we always know to
> 1-second precision?  Ah, but the author stamp doesn't change when
> author-attributed patches are replayed onto a repository with git am,
> while the commit date does.  The author date is a property of the patch,
> the committer date an artifact
> 
> Unfortunately, author attributions mined from ChangeLogs only have
> time specified as a a date.  In an attempt to minimize the worst-case
> distance from the actual time of authorship, I add on a time part of
> 12:00:00Z.  Kind of doomed since we don't know the submitter's time
> zone, but I had to pick something and noon UTC will work pretty well
> for Europe and the U.S.
> 
> This gives rise to another problem - lots of noon timestamps colliding
> with each other (making for non-unique action stamps if one author has
> multiple commits on the same day).  One thing I think I know
> is that order of attributions in a ChangeLog is usuall the time order,
> so I add a tick to the timetamps to separate them.
> 
> Maybe it would be better to copy the committer time if it's on the
> same day as the ChangeLog entry. We still have to deal with the
> other case, though.

Oh, you are trying to add Author information that coincides with the 
ChangeLog date.  I was just thinking that CVS doesn't have an Author and 
Committer date/time so whatever the CVS checkin time is becomes both 
those date/times in git.

If the date/time is the same, just add an hour (or tick), but of course 
if there are more than two such date/times then one has to be careful to 
continue checking.  That is, we can't do

Assume:
dt25 == dt26 == dt27

First comparison:
dt25 == dt26  >  dt26++

Second comparison:
dt25 == dt27  >  dt27++

because then dt26 and dt27 end up equal.

Is there a situation if the commit time on a given day is 9:00 am and 
the assigned author date is the same day 12:00 pm that the author 
date/time ends up ahead of committer date/time?  That would be odd.

Ethan, et al.  Would you be fine with the committer time and author time 
always being the same?  The ChangeLog entry date probably isn't real 
accurate in itself, is it?

Dan

Re: Re: Re: News spin of repository conversion

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

"Bastian Märkisch" <bma...@we...>:
> I can still identifiy a few missing and false attributions. I guess those
> could be included easily with the help of an additional input file, right?

Yes, but hold off onm that for a bit - I'm about to change the way those files
are generated.
-- 
		<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.