How would you explain the risks of the $Log$ keyword?

Question

I seem to get into an annual debate about the use of the $Log$ keyword. My point of view is this:

$Log$ is white hot death.

All it does is jam marginally relevant spam into your source files. Any information that anyone thinks they might be able to get from a $Log$ is more readily available from (and is likely to be more accurate in) your version control system.

So, here's the question: how would you explain to an "old school" coder (who thinks that $Log$ is the way to manage source code changes) that we have better tools now?

The CVSNT remarks on $Log$ are a good start but they're just not pointed enough. To date, the closest that I've come to a one-liner that I've managed to come up with is "$Log$ is a wish. You're hoping that what gets spammed into your file has any relation to what really happened to this file."

PS for clarity: when I say "old school," I mean old in attitude, not old in years. My first programming paycheck (and a remarkably modest one it was, too) was sometime in 1986 and I never thought $Log$ was a good idea.

Answer 1

I think the Subversion FAQ also has a good explanation.

$Log$ is a total horror the moment you start merging changes between branches. You're practically guaranteed to get conflicts there, which -- because of the nature of this keyword -- simply cannot be resolved automatically.

Answer 2

In addition to what the others have said, try putting a comment (/* ... */) into a commit message :->.

Answer 3

The amount of useful bits in a source file slowly decreases as changes are made to it with that $Log$ statement in it. We had it in some files that came from CVS and number of lines of $Log$ statements was on the order of 10x longer than the executable code in file actually was. And it had a few groups of duplicates caused by bad merging from some branches.

Answer 4

You may consider (emphasis on may) embedding immutable meta-data in your file.
(See the debate between me and an "older schooler" : Embedded Version Numbers - Good or Evil?).

Even though I have always considered that practice as evil (mixing meta-data information into data), introducing "merge hell", one could argue that it could work, with the right merge manager, for immutable meta-data with a fixed format, like:

• $Revision$ $Revision: 9.13 $
• $Date$ $Date: 2009/03/06 06:52:26 $
• $RCSfile$ $RCSfile: stderr.c,v $

But mutable meta-data like logs ? With unknown format or content ? That is bound to fail.