[gentoo-dev] Re: ChangeLog generation - pros and cons (council discussion request)

[Duncan]

Fabian Groffen posted on Thu, 02 Jun 2011 11:13:38 +0200 as excerpted:

> Obviously, all history is lost.  VCSs other than CVS might keep history
> across moves here (svn, git, hg...), hence a "follow" could perhaps find
> renames.  Question is if this can be detected in such a way that a
> useful ChangeLog can be generated.  Will version bumps that are almost
> identical copies, that show up as copies/renames cause issues here?

Git, which has been described as a content tracker that happens to have a 
DVCS of the same name built around it, definitely follows moves/renames 
without losing history.  It even has an adjustable percent-change 
threshold at which a similar file is detected as a move/rename, for 
purposes of git-log and statistics generation.

The problem with autogeneration based on git log would then come down to 
the impedance miss-match between git as a content tracker and a file-based 
changelog.

For those with access to the full git repo and log, it isn't normally a 
problem since the content isn't lost, you just switch your git log 
filtering to include both locations instead of just one.  (And false-
positives aren't generally a problem either in that case, the human filter 
picks up on it pretty fast and rejects it /as/ a false positive, and the 
the git log filtering simply doesn't get changed.)  This of course is yet 
another factor in favor of allowing full git-pull access to all, the whole 
auto-generation thing becomes moot.

If full git-pull access is not allowed for all, however, or if the rsync 
sync options are retained as they likely will be in any case, then 
generated changelogs remains a valid consideration.

Perhaps the easiest approach in that case would be to simply take the 
limitation at face value, accepting that generated changelogs apply to 
only the current package name, and to lookup what happened before a move, 
one either does the full git checkout (if it's a public option) and looks 
there, or checks the gitweb, etc, status.

As for dealing with the existing history and changelogs, either the 
conversion scripts can take what they can get out of the CVS logs and 
settle for that, or the existing changelogs could be committed, then 
deleted and that committed, so anyone wanting to see the existing history 
at the time of the conversion could simply check the changelog as it was 
initially committed and then deleted.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman