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

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

On 10/09/2017 12:15 AM, Mojca Miklavec wrote:
> On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
>>
>> I have a question though.
>> We have a much longer list of contributors (as opposed to committers) because
>> the project workflow historically had a large number of contributors funneling
>> contributions through a small number of people with cvs commit privilege.
>>
>> I found 168 unique contributors listed in the ChangeLog files,
>> compared to the 14 committers in your list above.
>> Will the names of the true contributors be lost in the conversion process?
>> That would be sad.
> 
> 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.


> Mojca
> 
> 
> 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.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.117.2.7 of file src/mouse.c is tagged but not present
> revision 1.31.2.1 of file src/datafile.h is tagged but not present
> revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
> revision 1.31.2.1 of file src/datafile.h is tagged but not present
> revision 1.117.2.7 of file src/mouse.c is tagged but not present
> revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.3 of file docs/pdffigures.tex is tagged but not present
> revision 1.464.2.38 of file src/graphics.c is tagged but not present
> revision 1.464.2.38 of file src/graphics.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> revision 1.29 of file src/contour.c is tagged but not present
> Skipping #CVSPS_NO_BRANCH

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?

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.

Dan