Re: [flame] NEWS file is useless

[Richard Frith-Macdonald]

On 26 Nov 2009, at 11:08, Nicola Pero wrote:

>> So I guess the solution to that would be instead to require ChangeLog 
>> entries to be committed to svn log.
> 
> By the way, presumably we'd still include the author of the change in the 
> subversion commit message ?
> Ie, we write a full ChangeLog entry including the author at the beginning ?
> 
> The reason is that when we receive patches, the committer is often *not* the 
> author of the patch, only the reviewer.
> With ChangeLog entries you can see who is the author of the patch, regardless 
> of who did the actual commit.
> (and occasionally, some changes simply have two or more authors - again in 
> ChangeLogs you just list multiple
> authors, while subversion logs can only record the committer)
> 
> I'm personally not too convinced.  I guess it must be because I don't use any 
> tools based on subversion logs
> so I don't see a particular benefit.  Anyway, we can change things.

I'd ideally like to see the ChangeLog file maintained by the svn system (ie 
when you check in any change in svn, it updates the ChangeLog and stores the 
updated version in svn).  I seem to recall writing a script to do that on our 
old CVS system at Brainstorm.  Failing that, we could just have a system which 
regenerates the ChangeLog on demand (eg. 'make ChangeLog') and when making a 
snapshot/release.

Let's say that policy is that people should write full, detailed entries (like 
ChangeLog entries) for the svn logs.   Then it ought to be possible to take the 
output of 'svn -v log' and produce a reasonable ChangeLog entry listing the 
modification date, the files modified, and the log entry.  This would mean that 
the log entry had to apply to all files in the transaction, but I'm not sure 
that's such a bad thing.

So instead of

2007-12-08 Richard Frith-Macdonald  <address@hidden>

        * GNUmakefile: bump subminor version for release
        * GSThroughput.m: ([-description]) output information for periods
        from last cycle as well as current cycle.

You might get

2007-12-08 Richard Frith-Macdonald  <address@hidden>

        * GNUmakefile:
        * GSThroughput.m:
        Bump subminor version for release
        ([-description]) output information for periods
        from last cycle as well as current cycle.

In the first case I wrote the entire entry as a ChangeLog entry.
In the second case I would have written

Bump subminor version for release
([-description]) output information for periods
from last cycle as well as current cycle.

as an svn log entry,

However, I suppose a better log entry might have been:

Bump subminor version for release in make file.
([GSThroughput-description]) output information for periods
from last cycle as well as current cycle.

Possibly this was a poor example because the two changes are not really related 
and don't need to be in a single svn transaction.
I think, generally, when you commit a multi-file transaction, the changes 
normally are related, and having a single long entry describing the changes 
actually makes good sense.