Re: Why have a ChangeLog file if you already have commit messages?

["Sanford Armstrong" <sanfordarmstrong gmail com>]

On 9/16/07, Havoc Pennington <hp redhat com> wrote:
> Hi,
>
> On 9/15/07, Jaap Haitsma <jaap haitsma org> wrote:
> > Talking to Daniel "Cheese" Siegel we asked ourselves:
> > Why do all GNOME projects have a ChangeLog file?
> > Isn't it redundant when you just save a commit message.
> >
>
> When I've seen projects just dump CVS or SVN log to ChangeLog,
> typically the resulting ChangeLog sucked badly; most commit messages
> are not very good, while ChangeLog entries frequently are. Why the
> difference? Who knows. It is a real difference whether there's a
> logical reason for it or not though.

(snip)

> I guess the summary is, the focus should be on whether people write
> good change history messages, and maintainers should probably feel
> free to use any mechanism that works for them for that. But as soon as
> messages start to be useless, like "fixed stuff," "hacked on foo.c,"
> it's a problem no matter what technology is used to save the messages.

This has become a non-issue for Tomboy since we started using
MonoDevelop's version control and ChangeLog integration.  If you check
out this (old) post on Lluis Sanchez's blog [1], you'll see what great
ChangeLog/commit integration can look like.  Lluis' screenshots [2][3]
tell the story better than I can, but basically there is a version
control "status" window with a top pane showing modified files (with
expandable diffs) and a bottom pane where you enter your changes for
each file.  This information is consolidated into a well-formatted
commit message that is also prepended to an appropriately-located
ChangeLog *before* committing.

This helps create better history messages because you have the
relevant diffs right there with you as you're typing up your messages.
 And you're not frustrated about wasting time typing in file paths and
switching contexts, so you're more likely to take time making nice
messages.  :-)

I know not everybody likes IDEs like MonoDevelop or operating systems
like emacs, but I think this is clearly a superior workflow approach
that maintains existing GNOME practices.  I'm sure this functionality
could be put into a standalone tool for everybody to use (command line
or otherwise).

Cheers,
Sandy

[1] http://foodformonkeys.blogspot.com/2007/02/more-on-monodevelop-work.html
(section titled "Improvements in Version Control")
[2] http://bp3.blogger.com/_cHnO0qtZD7s/RcI53XeaPZI/AAAAAAAAAA0/4ofHLVlHQg8/s1600-h/CapturaCSharpBindingStatus.png
[3] http://bp0.blogger.com/_cHnO0qtZD7s/RcI8jneaPaI/AAAAAAAAAA8/cuEUIzyYwRQ/s1600-h/CapturaCommitFiles.png