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

[Mojca M. <moj...@gm...>]

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.

>> PS: w.r.t. the question of what could go wrong with my conversion,
>> this is what the "git cvsimport" complains about:
>>
>> revision 1.3 of file docs/pdffigures.tex is tagged but not present
>> revision 1.29 of file src/contour.c is tagged but not present
...
>> Skipping #CVSPS_NO_BRANCH

I need to add that this comes from "git cvsimport" (which is
considered buggy). But just to show a partial answer to "what's wrong
with the repo on github".

> 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".

> 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.

On 9 October 2017 at 08:21, sfeam wrote:
>
> True.  So as long as the original commit dates are retained in some form,
> the modified files can still be mapped to the ChangeLog description and
> hence the original author.  OK.
>
>         Ethan

The timestamps are (usually) retained. I'm not 100% sure, but I seem
to remember that CVS is not timezone-aware and would accept whatever
date the committer has set on his machine.

Mojca