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