Re: CVS woes

[Eric S. R. <es...@th...>]

Allin Cottrell <cot...@wf...>:
> On Mon, 23 Nov 2015, Daniel J Sebald wrote:
> 
> > On 11/23/2015 03:46 PM, Allin Cottrell wrote:
> [...]
> >> Any plans for gnuplot to migrate to git? That seems to be _much_
> >> better supported at sourceforge.
> [...]
> >
> > One of the requirements is that the git log output would have to 
> > be converted to ChangeLog format using some type of script for 
> > development moving forward. And it would be good for the existing 
> > ChangeLog to serve as the commit messages for the initial git 
> > repository.
> 
> This may not be exactly what you're talking about, but currently 
> available software will translate the entire history of a CVS 
> repository into the git equivalent -- making for a seamless 
> transition -- so I don't suppose that handling ChangeLogs would be a 
> problem.

It depends on what the maintainers actually want.  I speak as an
expert at this kind of conversion; among other things, I moved
groff and NUT from CVS to git.

Unfortunately, the combination of ChangeLogs and CVS comments is actually very
difficult to integrate into a single comment history.

The first step would be mapping the per-file CVS commits to git-style
multi-file commits.  I maintain the best-in-class tools for this -
cvs-fast-export and reposurgeon - and unless your CVS repo has
particularly odd malformations it won't be difficult.

I just ran a test conversion of your SourceForge CVS; took about 5
minutes to do it and correctness-check the result at every tag. There's
some mild hinkiness with an import branch that can probably be
discarded, and three file histories under docs/ps that should probably
be snipped off, but for a conversion of a CVS repo this old that is
barely any cruft at all, and reposurgeon could fix it right up.

It also wouldn't be any real problem, mechanically speaking, to edit
individual change comments to include ChangeLog entries.  The problem is
in figuring what commit each entry should be inserted into.  Their dates
are only recorded to the day, so it isn't usually going to be possible
to mechanically associate a ChangeLog entry with a single commit.  Even
the disambiguation of being able to match against committer names turns
out not to help much.

But the real show-stopper is that, if this project is anything like
typical, a single ChangeLog entry often actually summarizes work from
*multiple* commits.  It may not be clear which ones, since one of
the bedevilling quirks of older CVSes was that commit timestamps were
take *client-side* and tended to be flaky.

You'd have to have some human slog through all ChangeLog entries by
eyeball, applying contextual knowledge and editing ChangeLog entries
into the commit history by hand.  I know of no project that has ever
actually done this.

What everyone ends up doing when they convert is treating ChangeLogs as
historical documents related to but not merged with the commit history.

Now, as for generating ChangeLog entries after conversion.  It can be
done, but it's like mounting an ornamental buggy-whip holder on the
dashboard of a car - quite pointless in practice.  When you have a
proper VCS with multi-file commits, those should *be* your Changelog.
Enough said.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>