Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)

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

On 10/11/2017 08:16 AM, Eric S. Raymond wrote:
> sfeam <sf...@us...>:
>> It looks to me that there is general consensus that
>>
>> - we should move to git,
>>
>> - that Eric Raymond's toolset is the best way to do that, and that
>>
>> - if Eric himself is willing to guide the conversion it has the greatest chance of success.
>>
>> So let's do that.
> 
> This is a good time for me to do it.  NTPsec 1.0 just shipped and our PM said
> he didn't want to see any commits for a week. :-)
> 
>> Eric - several people responded with bits and pieces of meta-info that
>> you asked for.   Do you have everything you need?
> 
> Not yet.
> 
> 1. Here's the committer map:
> 
[snip]
> 
>     Ideally, we'd enhance this in two ways.  First, those of you with preferred
>     email addresses should make sure this points at the one you want. Second,
>     we'd add timezone offsets.

I didn't know timezone offsets for individuals is possible.  How is that 
advantageous in terms of git usage?  Is it that when git displays stuff 
to the user it adjusts date/time?  Does that happen in viewers like 
gitg, "git gui", etc.?


> 2. If you want the authorship data to be right, somebody's going to have to
>     write code to grovel through the ChangeLog(s) and generate
>     date/author/filelist triples. (Then I'll have to write some custom Python
>     to use those.) Though maybe this isn't worth it - the only
>     ChangeLog I can see only seems to cover 1998-2000.

I've written a utility that constructs the list you are looking for by 
examining all the ChangeLog diff hunks after the repository is 
translated.  The code is here

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

and the algorithm is based on searching the diff hunks for the first 
changed line (i.e., "+" in the first character) after the "+++" of the 
headers.  After finding that first change, it searches backward for the 
author info of the ChangeLog on that particular version.  Providing 
enough context lines in the diff hunks should allow capturing that 
authorship line.

Example usage is:

git log -p --unified=50 ChangeLog > ChangeLog.diff
git_changelog_author ChangeLog.diff > author.txt

(I suppose I could have written the utility to allow pipe redirection to 
skip the intermediate file.)  Examining the ChangeLog.diff file in an 
editor should go a long way to understanding how the algorithm works.

The output is gitID/Date/Author/Address separated by space character 
(allowing the Author to have spaces as well).  The date information is 
of no use to reconstruction in the git repository--as I explained in a 
previous email, any particular ChangeLog entry can be constructed 
piecemeal over the course of a day.  (But the utility should properly 
assign the same author info to all the incremental changes.)

I would think a python script could step through the list and 
retroactively call some git command to correct the authorship.  That 
would be nice.  I hope it doesn't make an entry in the git repository 
for every authorship change somewhere, though, as there are over 6000 
authorship lines.  (BTW, those changesets that had no modification to 
ChangeLog go unrecognized by the utility, but that's fine.)

I notice in the list of authorship there are some variations on 
names/address.  For example, Ethan is most often E. M., but often it 
appears E. A. M.  Do we want to make names consistent?  Those sort of 
variations are probably going to happen going forward in git as well, 
seeing as any particular person might do mods from different computers 
with slightly different user info configuration.

The list of files would come from the git repository changeset itself, 
but honestly I don't think that's of any benefit without any comments to 
go along with it.  Two reasons: 1) If it is just a list of files, that's 
already gotten from something like gitg viewer which lists all the files 
modified in a particular changeset, and 2) conveniently the name 
"ChangeLog" often being the first in the list puts the diff hunk for the 
ChangeLog right after the description so we sort of have the info format 
we want already, e.g., from gitg:

broeker <broeker>
10/06/2017 06:35:09 PM +0000
Use  if available. Provide centralized fall-back of WEXITSTATUS if  does 
not supply it.
Expand all 0a3035e39a1f9402a474d0ea9300deac4cd9ef33
....	....	 	
▼15	ChangeLog
....	....	 	@@ -1,3 +1,14 @@
1	+	2017-10-06  Xxxxxx Xxxxxx  <xxxxxx@xxxxxx>
2	+	
3	+		* src/command.c: Move WEXITSTATUS fall-back definition away from here.
4	+	
5	+		* src/syscfg.h: Include <sys/wait.h>, if it exists.
6	+		(WEXITSTATUS): Provide fall-back definition, if none in
7	+		<sys/wait.h>.  Move MS Windows specific replacement from command.c
8	+		to here.
9	+	
10	+		* configure.ac: Add call to AC_HEADER_SYS_WAIT
11	+	
1	12	 	2017-10-06  Xxxxxx Xxxxxx  <xxxxxx@xxxxxx>
2	13	 	
3	14	 		* config/mingw/Makefile:  Add helpfiles to "all" target, including

The above works for me, as far as retrieving a more detailed description 
of the changeset, i.e., no need to consult historical ChangeLog on this one.

A discussion worth having (gnuplot group) is what to do with the 
ChangeLog going forward.  Rather than

ChangeLog
ChangeLog.0
ChangeLog.1
ChangeLog.2
ChangeLog.3
ChangeLog.4
ChangeLog.5

it might be nice to put all those in some file ChangeLog_CVS or 
ChangeLog_historical--something that indicates this is really no longer 
an active file and all such info (similarly formatted descriptions) will 
be in the git changeset comment going forward.

Also, leaving said file in the root directory is best because I often 
use "grep */*" to quickly search for information in the source tree and 
prefer not all sorts of entries from the ChangeLog appearing in the 
search list.


> 3. There was some talk of gluing to the history old releases that only
>     exist as tarballs.  That can be done, but I need those tarballs.

If you were to first create a draft posted somewhere, we could clone the 
repository and test whether the tags for a particular version will 
retrieve code that matches the tarball.  If so, then we don't need tar 
balls within the repository, do we (group)?

Dan