6

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.

Bob Cross
  • 22,116
  • 12
  • 58
  • 95

4 Answers4

8

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.

Stefan
  • 43,293
  • 10
  • 75
  • 117
4

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

starblue
  • 55,348
  • 14
  • 97
  • 151
2

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.

Jay R.
  • 31,911
  • 17
  • 52
  • 61
1

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • I actually like the $Id: $ keyword because it is pretty much a last-one-wins tag. If any change was committed, there will be some sort of delta. It's also nicely low bandwidth. – Bob Cross Apr 08 '09 at 20:24