Why maintain traditional detailed ChangeLog in modern world (with SVN, Mercurial, Git)?

Question

Detailed ChangeLog entry usually tell who, when and what function changed and for why this change done.

And this for every separate function in the source code tree!

As I understand ChangeLog come from past when there were no good VCS.

So traditional ChangeLog doesn't need at all as you can get it all from:

  $ svn log .
  $ hg log .
  $ git log .
  $ bzr log .

Only one possible needs for ChangeLog for short summary between product versions and intended for user only (for example, when new version come, developer prepare ChangeLog describe notable/visible changes).

Or I am wrong?

From http://autotoolset.sourceforge.net/tutorial.html#SEC45 :

The ChangeLog file: Use this file to record all the changes that you make to your
source code. If your source code is distributed among many subdirectories,
and there is reason enough to think of the contents of the subdirectories
as different subpackages,then please maintain a separate `ChangeLog'
file for each subdirectory.

Look archaic and dogmatic. ChangeLog required by autotools and by "GNU coding standards".

GNU Emacs source contain a lot of huge ChangeLogs (many split by many parts):

  $ find emacs-22.3 -name "ChangeLog*" | xargs cat | wc -c
13605747

I can get summary log from Emacs bzr repo for about 1 min and search through it instead search for each separate ChangeLog and with modern tools like Emacs VC or Tortoise SVN/HG immediately get diff for change.

UPDATE Rationale to use ChengeLog come from dumbness of RCS/CVS servioning control system. Check http://www.red-bean.com/cvs2cl/changelogs.html section "ChangeLogs and the CVS log". All modern VCS provide/allow that criticize by this article in CVS.

Also there exist a lot of sctipts that convert your VCS history to ChangeLog style. So reject all of your ChangeLog's.

If you want provide user oriented info of features/back compatibility/etc between versions use NEWS file: http://www.gnu.org/prep/standards/html_node/NEWS-File.html

Answer 1

With distributed VCS, it has become a standard to "Commit Early, Commit Often". With such approach, you will end up with more commits than you have actual new features or bug fixes. The changelog is supposed to summarize the changes to the application as a whole. The VCS log on the other hand shows history of the source code, i.e. how did the feature end up being implemented.

Answer 2

As you say, a manually maintained change log can be useful as a summary of user-visible changes, or as an overview of large-scale changes that might be hard to determine by looking at a lot of individual commit messages.