我似乎每年都会讨论$Log$关键字的使用问题。我的观点是：
$Log$白死病。
所有这一切都是在源文件中堵塞了相关的垃圾邮件。任何人认为他们可能从$ Log $获得的任何信息都可以从您的版本控制系统中获得（并且可能更准确）。
所以，问题是：您如何向“老派”编码员（他认为$ Log $是管理源代码更改的方式）解释，我们现在有更好的工具？
The CVSNT remarks on $Log$ are a good start但他们只是没有足够的指向。到目前为止，我已经设法提出的最接近单行的是“$Log$是一个愿望。你希望得到垃圾邮件在你的文件中有任何与这个文件真正发生的关系。“
PS为清晰起见：当我说“老派”时，我的意思是陈旧，多年不老。我的第一个编程薪水（也是一个非常适度的薪水）是在1986年的某个时候，我从未想过$ Log $是一个好主意。
答案 0 :(得分：8)
我认为Subversion FAQ也有很好的解释。
当你开始合并更改时，$ log $总是令人恐惧 分支之间。你几乎可以保证在那里发生冲突， 哪个 - 因为这个关键字的性质 - 根本不可能 自动解决。
答案 1 :(得分：4)
除了其他人所说的内容之外，请尝试在提交消息中添加注释（/ * ... * /）： - ＆gt;。
答案 2 :(得分：2)
源文件中的有用位数随着对其中的$ Log $语句所做的更改而缓慢减少。我们在一些来自CVS的文件中得到了它，并且$ Log $语句的行数比文件中的可执行代码长10倍。并且由于某些分支机构的合并不良导致了一些重复的组合。
答案 3 :(得分：1)
您可以考虑（强调可能）在您的文件中嵌入不可变的元数据。
（参见我与“老同学”之间的争论：Embedded Version Numbers - Good or Evil?）。
尽管我一直认为这种做法是邪恶的（将元数据信息混合到数据中），引入“合并地狱”，但人们可以说它可以通过合适的合并管理器来实现不可变元 - 具有固定格式的数据，例如：
但可变的元数据如日志？格式或内容未知？这肯定会失败。