Re: Roundup of GNUPLOT conversion issues

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

Daniel J Sebald <dan...@ie...>:
> >That would be slightly wrong because 3.7.0 is not on the branch.  It's on
> >the trunk.
> 
> This is correct.  GNUPLOT_RELEASE_3_7_0 is on the trunk while the other
> GNUPLOT_RELEASE_3_7_x are on the branch.  I'm attaching screenshots of the
> cvs2git tree and the cvs-fast-export tree after I've made the rebase with
> reposurgeon.  The GNUPLOT_RELEASE_3_7_0 synthetic commit was done by
> cvs-fast-export, not reposurgeon.  So, cvs-fast-export got the tag/branch
> correct but didn't realize that's where the pertinent branch should go.

Right, because that commit represents a broken (incomplete) tag set.
cvs-fast-export ignores those as branch point candidates because
there's no way to know that the checkout at that point is correct.

Which actually gives me an idea for a feature.  I could add a switch to
whitelist incomplete tags.

Here is a useful thing you can do while I try to fix the changelog scanning.
Modify reconvert so it doesn't delete that one branchlet, reparent the
3.7.x branch onto it, and compare the result at tip.

If there are no differences other than RCS IDs, I would whitelist the tag.
At that point we could consider the 3.7.x branch salvaged. 
-- 
		<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.