我似乎进入了关于$Log$关键字使用的年度辩论。我的观点是这样的：
$Log$是白热化的死亡。
它所做的只是将无关紧要的垃圾邮件塞入您的源文件。任何人认为他们可以从 $Log$ 中获得的任何信息都更容易从您的版本控制系统中获得（并且可能更准确）。
那么，问题来了：您如何向“老派”编码员（他们认为 $Log$ 是管理源代码更改的方式）解释我们现在有更好的工具？
CVSNT 对 $Log$ 的评论是一个好的开始，但它们还不够明确。迄今为止，我想出的最接近的单行词是“$Log$是一个愿望。您希望垃圾邮件发送到您的文件中的内容与实际发生的事情有任何关系文件。”
PS为了清楚起见：当我说“老派”时，我的意思是态度老，而不是岁数老。我的第一份编程薪水（也是一笔非常低的薪水）是在 1986 年的某个时候，我从没想过 $Log$ 是个好主意。
我认为Subversion FAQ也有很好的解释。
当您开始合并分支之间的更改时，$Log$ 是一种彻头彻尾的恐惧。实际上，您肯定会在那里遇到冲突，由于这个关键字的性质，根本无法自动解决。
除了其他人所说的之外，尝试将评论 (/* ... */) 放入提交消息中：->。
随着 $Log$ 语句对源文件的更改，源文件中有用位的数量会慢慢减少。我们在一些来自 CVS 的文件中有它，$Log$ 语句的行数比文件中的可执行代码实际长 10 倍。并且它有几组由于某些分支的错误合并而导致的重复。
您可以考虑（强调may）在文件中嵌入不可变的元数据。
（请参阅我和“老学生”之间的辩论：嵌入式版本号 - 好还是坏？）。
尽管我一直认为这种做法是邪恶的（将元数据信息混合到数据中），引入了“合并地狱”，但有人可能会争辩说，使用正确的合并管理器，它可以适用于具有固定格式的不可变元数据，像：
但是像日志这样的可变元数据？格式或内容未知？那是注定要失败的。