[RFC] Policy change for ChangeLog

[Derek Atkins]

I just thought of the one reason this proposal really bothers me.
I knew there was something that wasn't sitting right and why I didn't
think this would work.  It's not that I'm against making developers
lives easier, but I want to make sure we don't lose something in kind.

I like the ability to specify what changed in each and every file.
Even when I commit a single feature, I like being able to specify
what I needed to change in each file to make that feature work.
I like being able to say:

   foo.c:  did this change
   bar.c:  did this other change
   quux.c: made yet another related change

And then have the overarching description:

   Made a bunch of changes to implement _foo_

When you leave the ChangeLog generation out of the developer's hands,
you can't get this level of detail.  All you get is the overarching
description.  You lose the ability to say what happened in each file.
Maybe you don't document your changes enough to want that ability,
but I do.

As for how to get the list of files changed, you can just run a diff:

  svn diff | grep '^Index'

Personally I feel you should always run an "svn diff | more" prior
to the commit to make sure you're only committing the change(s) you
want.  Note that unlike cvs, an svn diff does not touch the network.
Indeed, you could even create your ChangeLog entry as you're perusing
your svn diff prior to commit..  Then C-x C-s the ChangeLog buffer,
M-w to copy the changelog entry, and then C-y once you get the svn commit
log buffer.  Then just type what you want for the email subject in
the top line of the buffer and you're done.

-derek

Quoting Chris Shoemaker <c.shoemaker at Cox.net>:

> On Fri, Dec 02, 2005 at 12:20:25PM -0500, Derek Atkins wrote:
>> Quoting Chris Shoemaker <c.shoemaker at cox.net>:
>>
>> >Hmm, seems to be in the same vein as rcs2log and cvs2cl.  It's a bit
>> >more complicated than I'd like, but I guess that's the price paid for
>> >such precise control over formatting.
>>
>> *shrugs*  I figured I'd throw it out.
>
> Well, I looked more closely at the xsl and I'm warming up to it.  It's
> not nearly as complicated as I expected, and it does produce prettier
> output.
>
>>
>> >>I don't particularly like this option, but it's something to
>> >>consider.
>> >
>> >Is it more the concept of deriving ChangeLog at dist-time that you
>> >don't like or this implementation using xsltproc?
>>
>> I don't like the concept of deriving the ChangeLog.
>
> Just an idea: What if there was a "make ChangeLog" target that
> triggered on dist but could also be made by anybody who wanted a local
> ChangeLog file?
>
>> I see nothing
>> wrong with generating the ChangeLog by hand and then cut-and-paste
>> the log message into the commit-log.  It's what I've always done, and
>> as far as I can tell it's what everyone else does.  Create once, save
>> twice.
>
> I don't know how to create the changed-path list without visting every
> buffer I changed.  (or recall changing)  I've been using diffstat.
>
> -chris
>

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available