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

[Hans-Bernhard B. <HBB...@t-...>]

Am 08.10.2017 um 02:15 schrieb Daniel J Sebald:
> On 10/07/2017 06:05 PM, Mojca Miklavec wrote:

>> I decided to delete "missing" and "config/djconfig.sh" on purpose
>> because I had problems whenever I tried to build gnuplot.

For "missing" that might make some sense, since that file should never 
have been checked in to begin with --- it's supposed to be supplied by 
automake.

But I cannot imagine how a script used only to build gnuplot for MS-DOS 
could ever, possibly disrupt operations on other platforms, where it 
will never be used for anything.

>> Even if this conversion would serve as a starting point, here's still
>> a TODO list:
>> - "convert" .cvsignore to .gitignore (this could either be done
>> "properly" for all commits or just for the last commit)
> 
> Properly for all commits sounds difficult.  I suppose the two files have 
> pretty much the same form, given no comment characters or anything are 
> in .cvsignore; it's just a list of files.  Could we somehow create a 
> link from .gitignore to .cvsignore for older entries and then starting 
> with the new entries remove the link and rename .cvsignore to .gitignore?

The tools offered by Eric S. Raymond do this automatically.  They build 
.gitignore files to track the .cvsignore changes fully, including 
entries to make git ignore all those files that CVS ignores by default.

>> 1.) Wrong date extraction for $Id fields

That should solve itself as we remove the $Id entries from the source 
--- that's if we do go for git instead of SVN.

>> 2.) It's explicitly suggested that one should not use incremental
>> updates of the repository, but rather create a single conversion. I
>> don't know what consequences that might have.

This is mainly a problem only for your current situation, where CVS is 
the master repository, and git only used to track it.  What we're up to 
now is to make a git repository that's to be come the master itself.

>> 3.) I remember seeing the same cvs commit (which needed a couple of
>> minutes to be uploaded to the server) split in two git commits just
>> because of the varying timestamp.

The problem goes deeper than that.  There is, ultimately, no such thing 
as a multi-file commit in CVS (i.e. no "change sets").  Even a single 
client-side invocation of 'cvs ci' is to the server just a loose 
sequence of individual file commits that just happen to be close in 
time, and with the same check-in description.  Tools try to stitch those 
sequences back together again, but they cannot be perfet.

And that's before you come to users or cvs clients who, for whatever 
reason, really do perform multiple check-ins one by one even if they do 
form a coherent group.

>> 4.) If one deletes a folder in CVS, the files are probably gone
>> forever and one doesn't get them in conversion.

The files are still there in the CVS archive.  There is, e.g., a folder

	doc/Attic/ps/Attic

in the archive that holds the deleted contents of the deleted folder 
doc/ps.  At least one of the tools on offer says it cannot use the 
contents of that folder, though.

>> 5.) I had some issues with files that only differed in case and I got
>> "lossy conversion" (files lost) on my Mac (this conversion is done on
>> Linux though).

I think that means the transformation really has to be done in a 
case-sensitive environment; probably Linux.  We shouldn't accept lossy 
conversion if at all avoidable.

> I don't think I explained that well enough.  I didn't mean to do the 
> work of slice-and-dice all the individual entries of ChangeLog.0 through 
> ChaneLog.5 and ChangeLog.  What I meant was that all the ChangeLog.0 
> through ChangeLog are concatenated into one big comment and that comment 
> is the first entry of creating the new repository.

Oh hell no.  Turning all 1.7 MB of ChangeLog in to a single gargantuan 
log message would serve no purpose other than to annoy casual viewers. 
If we can't get ChangeLog mapped into the check-in messages entry by 
entry, then it has to stay out of there.

ChangeLog entries and check-in comments are, by design, separate 
documentation streams, serving different purposes.  Check-in messages 
are to keep others appraised of what a change is about, whereas 
ChangeLog is for looking up details during the work, without having to 
ask the server all the time.

Sometimes a single ChangeLog entry will cover multiple changesets 
(because a single person checked in multiple changes in a single day), 
sometimes a single changeset will affect multiple ChangeLog entries 
(e.g. if a previous entry was corrected later).

ChangeLog entries are supposed to be more detailed, mentioning exact 
locations of changes, and describing what exactly was changed, in which 
files, and how.  Check-in comments, OTOH, are usually kept short, to the 
point of terseness.  Most are a single line, and they only describe what 
the change was for, but not how it was achieved.

Git users advocate a similar use by splitting a commit message into a 
single-line summary (equivalent to typical CVS check-in comments), and 
the longer description below that, after a blank line.  So if ChangeLog 
entries can be moved into the log, they could become the bottom part of 
individual log entries.  If they can't, so be it.