Menu
▾
▴
Roundup of GNUPLOT conversion issues
|
From: <es...@th...> - 2017-10-29 05:30:21
|
The latest GNUPLOT conversion-machinery tarball, available as usual at
wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz
cleans up a number of minor issues, including:
(1) Patching out CVS release numbers in comments.
(2) Better explanatory text and comments for the very early section of
the repository.
(3) Patch that incorrect author date due to a ChangeLog typo.
I shall round up my responses to all recent traffic and then propose
what to do next.
Bastian Märkisch:
>Unfortunately, the last problem we discussed is not solved, though:
>If there's an insertion into the ChangeLog below an existing author line,
>the current algorithm picks the author line _below_ instead of the one
>_above_. This happens quite frequently and currently still leads to hundreds
>of wrong attributions.
>For examples try:
> git log --author=Ethan --committer=Bastian --oneline | wc -l
I still need an example pair of Changelogs with a difference that
triggers this bug. Given that, I can (a) fix the bug, and (b) add it
to my regression tedt so we can be certain it does not recur.
Daniel Sebald, Fri Oct 27 12:50:51 2017
> These files with the
>wrong RCSid and the demo-file discrepancies and the backward-progressing
>copyright dates reside in the master branch *until* some changeset resolves
>them. In the case of 3.7.x branch, there are a hundred "corrupted" files
>still, but shortly after 3.7.0 was completed there was a mass restructuring
>which moved files like alloc.c to a new subdirectory. That action resulted in
>the correct files going forward, such that 4.x and 5.x series all match
>well...except for the 4.0 shim that Eric noted, probably a vestige still of
>what I described.
>So, we need to go back to the start of the repository and make sure those
>first few commits, the "Import of beta 340", etc. are done properly such that
>something like the following set of files all match in terms of stamped
>revisions and branches:
>How should we proceed Eric?
What I'm hearing is, exact for the demo shim I added, all the remaining
differences early in branches other than 3.7.x are incorrect RCS IDs.
What I think is that trying to get the RCS IDs perfect would be wasted
effort. One of my last patches removes all of those, anyway. It's
time to remember that the purpose of the repository transition is to
support development going forward, not to have a theoretically perfect
and literal transcription of the CVS history.
We wouldn't even *want* that kind of 'perfection' - the old-style
change comments wouldn't play well with git log, for one thing.
Daniel J Sebald, Sat Oct 28 14:48:42 2017
> 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?
Yes.
> 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.
There is, however, that known problem with the 3.7.x tip revision, which has
non-RCSid differences between the tip and the tarball.
For reference, here is HBB's explanation.
3.7.1 has one check-in to ChangeLog that's tagged but not tarred, and an extra
pair of quotes around a line in configure.in that tarred but not tagged:
diff -uwrp -x CVS cvs-3.7.1/ChangeLog gnuplot-3.7.1/ChangeLog
--- cvs-3.7.1/ChangeLog 1999-11-01 13:33:32.000000000 +0100
+++ gnuplot-3.7.1/ChangeLog 1999-10-21 16:15:07.000000000 +0200
@@ -1,7 +1,3 @@
-1999-11-01 Berthold Hoellmann <ho...@ge...>
-
- * docs/Makefile.in: Fix pdf target for compiling outside source dir.
-
1999-10-21 Lars Hecking <lhe...@nm...>
* configure.in: Fix compile/link on NeXT without side effects ...
diff -uwrp -x CVS cvs-3.7.1/configure gnuplot-3.7.1/configure
--- cvs-3.7.1/configure 1999-10-27 13:00:15.000000000 +0200
+++ gnuplot-3.7.1/configure 1999-11-07 16:57:22.000000000 +0100
@@ -2591,7 +2591,7 @@ fi
fi
-if test $ac_cv_lib_nsl_gethostbyname = no; then
+if test "$ac_cv_lib_nsl_gethostbyname" = no; then
echo $ac_n "checking for gethostbyname in -lbsd""... $ac_c" 1>&6
echo "configure:2597: checking for gethostbyname in -lbsd" >&5
ac_lib_var=`echo bsd'_'gethostbyname | sed 'y%./+-%__p_%'`
diff -uwrp -x CVS cvs-3.7.1/configure.in gnuplot-3.7.1/configure.in
--- cvs-3.7.1/configure.in 1999-10-22 20:29:24.000000000 +0200
+++ gnuplot-3.7.1/configure.in 1999-11-04 18:21:00.000000000 +0100
@@ -115,7 +115,7 @@ AC_SUBST(GNUPLOT_X11)
AC_PATH_XTRA
dnl Needed for LynxOS until AC_PATH_XTRA is fixed
-if test $ac_cv_lib_nsl_gethostbyname = no; then
+if test "$ac_cv_lib_nsl_gethostbyname" = no; then
AC_CHECK_LIB(bsd, gethostbyname, X_EXTRA_LIBS="$X_EXTRA_LIBS -lbsd")
fi
diff -uwrp -x CVS cvs-3.7.1/term/tgif.trm gnuplot-3.7.1/term/tgif.trm
--- cvs-3.7.1/term/tgif.trm 1998-12-16 20:48:20.000000000 +0100
+++ gnuplot-3.7.1/term/tgif.trm 1998-12-16 20:48:20.000000000 +0100
@@ -371,7 +371,7 @@ TERM_PUBLIC void TGIF_init()
fprintf(gpoutfile, "\
%%TGIF 2.15-p7\n\
state(%d,30,%u,0,0,%u,16,1,9,1,1,0,0,0,0,1,0,'%s',0,%u,0,0,1,10,0,0,1,1,0,16,0,0,1,
+1,1).\n\
-%%\n%% @(#)$Header: /home/hbbro/prg/gp/backup/cvs/gnuplot/term/tgif.trm,v
1.10 1998/12/16 19:48:20 lhecking Exp $\n%% %%W%%\n%%\n\
+%%\n%% @(#)$Header: /var/tmp/CVSROOT/gnuplot/term/tgif.trm,v 1.10 1998/12/16
19:48:20 lhecking Exp $\n%% %%W%%\n%%\n\
page(1,\"\").\n",
TgifPortrait ? 0 : 1, uActResolution, uActZoom, sActFont,
uActFontSize);
eTgifState = NEWPOLY;
Dan again:
> 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?
No, that's not it at all. All COOKIEPATCH does is *remove all RCS cookies
from the tree* (well,except for one diff in the doc directory where I
couldn't figure out how to rip them out without damaging the diff).
> 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.
Too little gain for too much effort. Once SourceForge shuts down CVS,
nobody will ever care about "cvs update -rXYZ" again.
Hans-Bernhard Bröker <HBB...@t-...>:
> >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'm not quite convinced Dan's analysis is correct. The branch isn't
> corrupt, it was just set up somewhat strangely at the time.
It's corrupt in the sense that because of the vendor-branch confusion we
not only can't guarantee that the gitspace sequence of commits really
matches the CVS development history, we can't even get the right tip
state out of the conversion.
The extent to which this is a CVS problem versus a git problem versus
a cvs-fast-export problem is really only of theoretical interest.
I've spent three weeks on this conversion and my patience for
wandering further off into the weeds is evaporating. It only
lasted this long because getting ChangeLog analysis right seemed
like a thing worth doing.
Can we please refocus on *finishing* this with changes that actually add
value for forward development?
> Vendor branches with other branches partially rooted in them cannot be
> collapsed or ignored. Nor can they be treated completely like ordinary
> branches (or conversion tools would have been doing that since day one).
I know. Vendor branches have been a huge pain in the ass on other
conversions I've done, too.
Here is what I suggest we do:
1. Drop the 3.7.x branch. Replace it with a branch consisting of just
the archived 3.7.[0123] trees in sequence (I now have them all).
2. Fix any remaining deficiences in ChangeLog scanning if possible.
3. Fill in the empty log comments that are left.
4. Wrap it up and call it done.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Morality is always the product of terror; its chains and
strait-waistcoats are fashioned by those who dare not trust others,
because they dare not trust themselves, to walk in liberty.
-- Aldous Huxley
|
