ChangeLogging commits to CVS

[Keith Whitwell]

Mathieu Lacage wrote:
> On Tue, 2004-12-14 at 10:56 +0000, Keith Whitwell wrote:
> 
>>Is there a reason why the ChangeLog entry can't be generated automatically 
>>from the CVS commit messages?  Am I missing something here?
> 
> 
> I can remember a lengthy discussion on that specific topic for certain
> modules of the gnome cvs server which refused to use ChangeLog files and
> relied on cvs to generate them from cvs commits. The result of the
> discussions:
> 	- people are lazy and use stupid cvs commit messages. A separate
> ChangeLog file helps them stay honest

I can see that being the case in some projects, but I think the quality of CVS 
commit messages on Xorg has been pretty good - or has it?

> 	- some people like to browse the file offline which is not possible if
> it must be generated from the CVS metadata.

I don't think that going to the CVS metatdata is an option as then you'd lose 
the point of the ChangeLog file (as described in a previous post) of 
describing groups of single file changes atomically.

I'm suggesting that the ChangeLog file continue as is, just be populated from 
the CVS scripts rather than by hand.  I believe the suggestion is already that 
the same message be used in both instances, but currently it is a 'by hand' or 
partially-automated task to do this.

By populating ChangeLog automatically, you could potentially increase its 
utility by logging the version numbers associated with each file in the 
commit.  Of course, at a certain point down this road you end up inventing a 
new version control system.

> 	- people do not like to rely on the unreliable CVS commit scripts to
> generate a single ChangeLog on the server because commits are not atomic
> so the ChangeLog file would contain commit collisions.

How frequently do we see non-serializable commits on Xorg?  Does this really 
happen?  Do developers in practice commit simultaneously to overlapping sets 
of files in such a way that the changes become interleaved?  Would it matter 
(from the perspective of the ChangeLog) if they did?

Acutally, by including the ChangeLog file in every commit, you guarantee a 
strong serialization of changes across the repository, I think.


Keith