Re: CVS woes

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

On 11/23/2015 08:08 PM, Eric S. Raymond wrote:
> 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.

Could the documentation be integrated into the git commit history in an 
approximate way?  Say, associate all the comments for a particular day 
with the last CVS entry for that date?  But it would have to be that the 
full Changelog header and date appears in the comment.  So for example, 
one commit message might have three Changelog entries listed.  It would 
only be an approximate alignment of commit messages and the changelog, 
but anyone who would go through the history to manually decipher and 
reconstruct things would be faced with an approximate association with 
what is in CVS anyway.


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

I doubt anyone is willing to volunteer to fix the whole history, but 
having an approximate alignment of messages would be convenient enough, 
I would think.


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

I suppose that wouldn't be too bad, but I don't like the idea of having 
a commit message history that is void of any context.  The nice thing is 
having a viewer that displays the diffs between versions along with an 
overall description of changes.


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

The git log is pretty close to Changelog format already.  I would think 
some tweaking is all that is needed to make the output very close.  Then 
if the original Changelog comments are in the git commit messages, a 
"git-to-changelog" conversion would be close to the original changelog 
plus new commits.

For those who haven't used git, or mercurial, I think you'd find it a 
very helpful tool beyond just the code maintenance portion of it.  I 
typically have something like TortoiseHg or gitg open so that it shows 
me what all the changes are for my local version of code which just 
helps organize things in one's mind, and one can easily pick and choose 
the code hunks that should be included in a commit/changeset, etc. 
Something I find very clumsy with CVS is generating diffs to post on the 
bug tracker or whatnot.  But with git/hg this sort of operation is easy. 
  Basically, programming is just a much more fluent thing with a good 
version control system.

Dan