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

Question

I seem to be participating in the annual debate about using the $Log$ keyword. My point is this:

$Log$ - white hot death.

All it does is spam in your source files for a short time. Any information that anyone can get from $ Log $ is more easily available (and most likely will be more accurate) in your version control system.

So, the question is: how would you explain the “old school” encoder (which believes that $ Log $ is a way to manage source code changes) that we have better tools now?

CVSNT's remarks in $ Log $ are a good start , but they are just not pointed enough. To date, the closest thing that I came to one liner that I managed to come up with is " $Log$ is a wish. You hope that what gets into your file has something to do with what really happened with this file. "

PS for clarity: when I say "old school", I mean the old attitude, not the old one for years. My first programming salary (and remarkably modest one) was also 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 complete horror when you start merging changes between branches. You are almost guaranteed to get conflicts there, which - due to the nature of this keyword - simply cannot be resolved automatically.

Answer 2

In addition to what others have said, try putting a comment (/ * ... * /) in a commit message: →.

Answer 3

The number of useful bits in the source file slowly decreases as you make changes to it using this $ Log $ operator. We used it in some files obtained from CVS, and the number of lines of $ Log $ statements was about 10 times longer than the executable code in the file actually was. And he had several groups of duplicates caused by poor merging with some branches.

Answer 4

You can consider (emphasizing perhaps) embedding immutable metadata in your file.
(See Discussions Between Me and the High School Student : Are Embedded Version Numbers Good or Bad? ).

Despite the fact that I always considered this practice to be evil (mixing metadata information with data), presenting "merge hell", it could be argued that it could work with the right merge manager for immutable fixed-format metadata , for example:

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

But mutable metadata like logs? With an unknown format or content? This is bound to fail.