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

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

On 10/09/2017 02:12 AM, Mojca Miklavec wrote:
> On 9 October 2017 at 08:30, Daniel J Sebald wrote:
>> On 10/09/2017 12:15 AM, Mojca Miklavec wrote:
>>>
>>> They are actually "lost" is CVS already, while they are (and will)
>>> still (be) in ChangeLog.
>>>
>>> What one *can* do with cvs2git conversion is to start with something
>>> that looks like a reasonable conversion already and then make a map
>>>
>>>       <commit-shasum> <author>
>>>
>>> for all commits where the author doesn't match the committer. Then one
>>> can run a script that changes the author of each individual commit.
>>
>> This is what I was wondering about, i.e., an iterative approach where it
>> might not be correct on the first pass but then somehow run a script or
>> program that cross-references comments and adds or removes author info to
>> keep everything in sync.
>>
>> I thought that the git database was encoded such that changing authorship
>> wouldn't be so easy unless there is a git command that does so.
> 
> This is one of the reasons why I like git a lot. You can basically do
> whatever you please with a git repository. In contrast to subversion
> (and also mercurial ot a large extent), changing the history of a git
> repository is considered "normal" and there's built-in support to do
> very strange things. Or, if the support is not built-in, it's "easy"
> to write a python/perl/bash script to achieve what you want.
> 
> The main "problem" with assigning the correct author is getting the
> mapping right. That requires quite some man-hours, I guess. Doing the
> change on the git end is more or less straightforward.

As much automation as possible is preferred.  A script file to sort 
through the changed files and ChangeLog entry might give reasonably good 
alignment.  Consider the first two examples from the test repository. 
The "git log --stat" tells us what files have changed with each changeset:

GIT LOG
-------
commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33
Author: bbbbbb <bbbbbb>
Date:   Fri Oct 6 18:35:09 2017 +0000

     Use <sys/wait.h> if available.
     Provide centralized fall-back of WEXITSTATUS if <sys/wait.h> does 
not supply it.

  ChangeLog     | 15 +++++++++++++--
  configure.ac  |  4 +++-
  src/command.c |  6 +-----
  src/syscfg.h  | 20 ++++++++++++++++----
  4 files changed, 33 insertions(+), 12 deletions(-)

CHANGELOG
---------
2017-10-06  hhhh bbbbbb  <xxxxxx@xxxxxx>

	* src/command.c: Move WEXITSTATUS fall-back definition away from here.

	* src/syscfg.h: Include <sys/wait.h>, if it exists.
	(WEXITSTATUS): Provide fall-back definition, if none in
	<sys/wait.h>.  Move MS Windows specific replacement from command.c
	to here.

	* configure.ac: Add call to AC_HEADER_SYS_WAIT

The above is a good match in terms of files that changed and the change 
log for that day.  Hence, in this case we would substitute Author hhhh 
bbbbbb  <xxxxxx@xxxxxx> for bbbbbb <bbbbbb>

But then the second example isn't so simple:

GIT LOG
-------
commit 1455f9768f84f061aade6a9d52c29dfd92f621db
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:52:24 2017 +0000

     Add menu items to edit gnuplot.ini and wgnuplot.ini

  ChangeLog            | 6 ++++++
  src/win/wgnuplot.mnu | 9 ++++++++-
  2 files changed, 14 insertions(+), 1 deletion(-)

commit c5031aa2e31adb4b98569da80f2eb65abd282310
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:43:05 2017 +0000

     Build and install support files for lua/tikz

  config/msvc/Makefile | 32 ++++++++++++++++++++++++++++++--
  1 file changed, 30 insertions(+), 2 deletions(-)

commit 6078650b9396c309b593f0395cb0ef6fa552329a
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:36:50 2017 +0000

     Add a note on secure APIs

  ChangeLog             | 3 +++
  config/mingw/Makefile | 4 +++-
  2 files changed, 6 insertions(+), 1 deletion(-)

commit b720450b7620be7a5946b851411e49eb8b791521
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:28:39 2017 +0000

     Default to Mingw-w64 and Direct2D v1.1

  ChangeLog             | 4 ++++
  config/mingw/Makefile | 6 +++---
  2 files changed, 7 insertions(+), 3 deletions(-)

commit 14ed6d64ad2375f33868ae9603fae9ce17f087c0
Author: mmmmmm <mmmmmm>
Date:   Fri Oct 6 07:23:19 2017 +0000

     Add helpfiles to 'all' target

  ChangeLog             |  5 +++++
  config/mingw/Makefile | 10 +++++-----
  2 files changed, 10 insertions(+), 5 deletions(-)

CHANGELOG
---------
2017-10-06  bbbbbb mmmmmm  <xxxxxx@xxxxxx>

	* config/mingw/Makefile:  Add helpfiles to "all" target, including
	the japanese version.  Remove helpfile from default target.

	* config/mingw/Makefile:  Default to Mingw-w64 and Direct2D v1.1.
	Note that building using Mingw32 currently does not work anyway
	due to missing headers libraries for newer Windows APIs.

	* config/mingw/Makefile:  Add a note that secure APIs are required
	(pointed out by Allin Cottrell on the mailing list).

	* config/msvc/Makefile:  Build and install support files for the
	lua/tikz terminal.

	src/win/wgnuplot.mnu:  Add menu items to edit gnuplot.ini and
	wgnuplot.ini to 'Help' menu.

So, this second example is sort of a series of commits in which 
ChangeLog entry was constructed piecemeal over time.  In that case, we 
probably wouldn't substitute bbbbbb mmmmmm  <xxxxxx@xxxxxx> for mmmmmm. 
But in all likelihood it is the maintainer who is building the changes 
and ChangeLog entry over the course of a day in this way, so the Author 
should be correct already.

And I'm going to guess that, generally, when Ethan has put together a 
ChangeLog entry for contributed work from a contributed patch, he pretty 
much does it as one CVS "commit" (i.e., more like the first example 
above).  He does go back and change typos and such after the fact, but 
such clean-ups can be left as is and attributed to Ethan.

So, if one were to write a script that goes through the "git log --stat" 
and whenever on a matching day there is a "ball of files" in a commit 
that matches to 90% a "ball of files" in a ChangeLog, substitute the 
Author info, otherwise leave the maintainer as Author; might that be 
good enough?


>> Hmmm, this probably comes about because of misalignment of changeset
>> groupings and the converters revision count.  That is, the CVS tag numbers
>> are translated in a way that doesn't agree with the original file versions.
>> Do all these complaints come at the very end?  That is, is the last version
>> of, say file src/graphics.c, 1.464.2.37?
> 
> I don't know and I'm not too eager to dig into it as it won't bring
> anything even if I "debug it".

I think doing a parallel reconstruction of a tagged version in both CVS 
and git (or SVN) with the idea in mind of making them file-by-file exact 
could lead to the most insight as far as alignment.  Those tags being 
correct is actually a little higher priority than having the exact 
contribution attributes by user per commit.


>> This makes me think that none of the tags after conversion will be reliable.
>> That's a pretty crucial issue, i.e., the ability to reconstruct program
>> versions older than the conversion date/time.
> 
> Well, one needs to be aware that there is one caveat with cvs -> git conversion.
> 
> CVS theoretically supports tagging strange combination of files that
> never existed together as such in the main branch. Getting the exact
> tag might not always be possible unless one first creates a branch
> with those exact versions of all files and then makes a tag on that
> branch. I don't know how Eric's tool handles that.

So, when a release is done currently, are a collection of files grouped 
into an archive file and that's the official release, sitting on a 
server somewhere?  It's not the tagged files in the repository that is 
considered the release?

Dan