Aw: New spin of repository conversion

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

Thank you for the new version.  Overall the attribution algorithm
seems to work remarkably well! There are a number of cases though
were it fails. 

Here's an example (picked more or less randomly):
https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/
This one is attributed to Ethan, although the change is by me.
The reason seems to be that the Changelog entry is inserted below
an entry by Ethan on the same day.  I think that is not an uncommon
case, in fact I quickly found around a dozen such cases.  Can this
be taken into account or do we have to check manually?

Another idea concerning the CVS conversion:  at the early stages of
the gnuplot CVS repo, files were moved from the top directory to 
sub-directories. That is they were deleted and added to CVS again. 
Hence the history before the move is kind of lost.  While not super
important, I wonder if this could be easily ammended now?

  Bastian


> Gesendet: Mittwoch, 18. Oktober 2017 um 19:58 Uhr
> Von: "Eric S. Raymond" <es...@th...>
> An: gnu...@li...
> Betreff: New spin of repository conversion
>
> I've pushed a version including the 1.1 release in its tail, and all
> previously missing tags should now be visible.
> 
> There are somewhere around 275 commits with empty comment fields.
> These should either have comments filled in or, if they are ChanegLog
> singletons that need to be glued to another clique, I need to know
> that.
> 
> I've enclosed a file named EMPTY which is in the right format to be
> read back in by reposurgeon. All of you, please fill in any comments
> you can in the commits you're responsible for; if you want to clue me
> in to a ChangeLog commit that should be squashed with the previous
> one, put SQUASH in the comment field.  Don't alter the divider lines.
> 
> The tags could use some cleanup.
> 
> Many of the earlier BETA tags are junk at this point - due to
> malformations in the CVS metadata they designate only incomplete sets
> of files and don't point at a real (gitspace) commit.  Instead they
> point at synthetic commits generated by cvs-fast-export, but what
> you'll get if you check out that commit is not reliably what was
> originally intended.
> 
> I've enclosed a list of these incomplete tags as BADTAGS.  Also
> a list of valid tags as GOODTAGS.
> 
> My recommended disposition: first, delete all the bad tags.  They're
> not actually fit for purpose, and make the repo look like it can restore
> state that it can't.
> 
> (We may be able to deduce correct replacements for some of the bad tags
> by comparing the history with saved release tarballs on SourceForge.)
> 
> Second, change all the good release tags to use the same convention.  In
> git-land, normal practice is just to use the bare release number as a
> release tag. So
> 
> GNUPLOT_RELEASE_3_7_1 -> 3.7.1
> Release_4_4_2 -> 4.4.3
> -- 
> 		<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.
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>