1

我注意到我们系统中的一些源文件存在差异，其中一些包含源代码控制签入注释，而另一些则没有。签入时，这些注释会自动添加到文件顶部：

    * $Log:   //vm1/Projects/Morpheus/Sleep.bdy-arc  $
--
--   Rev 1.14   Apr 14 2009 15:32:52   John Smith
--Fixed bugs 2292 and 2230.

这似乎在我工作过的所有公司中都很普遍，但我必须承认我很难理解这一点。一般来说，评论不是那么好，经常是那些早已离开的人留下的，即使它们的标准很高，也很难将它们与物理代码更改联系起来。

令我震惊的是，您实际上是在更改要签入的文件。现在，对于将要编译的文件来说，这可能不是这样的问题，但对于其他文件（例如 JavaScript 文件）来说可能是一场灾难。

所以真的，我的疑问是在第一个实例中提供此功能背后的概念动机是什么？真的有人觉得这些评论有用吗？

另外，我很想知道这是否是源代码控制系统中普遍支持的功能。我知道 PVCS、VSS 和 Subversion（Subversion Keyword Substitution），但我想知道它是否也适用于一些更流行的 DVCS。

一如既往地感谢您的帮助。

4

3 回答 3

5

你是对的 - 总的来说，这不是修订控制系统的一个非常有用的功能！是的，公司喜欢审计跟踪，但这是由版本控制系统的日志命令提供的；是的，这意味着如果版本控制系统不可用，则日志可用-但在这种情况下，Fixed bug 1234可能不是很有意义:-) 而且，正如您所暗示的，为了将更改绑定到特定行，您仍然需要版本控制系统的帮助。

您也是正确的，在提交文件时更改文件可能会导致问题 - 我曾经看到一个问题，一位同事仔细确保他的代码编译然后提交，只是因为他提交的文件没有不编译。事实证明，注释类似于Clean up /tmp/*.txt，C 编译器将/*视为注释开始字符（并抱怨，因为它已经在注释中）。

文件中日志的另一个问题是它们仅对线性工作有意义 - 一旦您使用多个分支进行开发（以 git/mercurial/bazaar 等分布式源工具所鼓励的方式），将源文件中的日志本身仅服务几乎一直在创建合并冲突。

出于这个原因，现代工具往往不会实现此功能。事实上，颠覆没有- 它的关键字替换故意不允许包含日志历史记录。

于 2010-05-17T14:37:59.070 回答
1

所以真的，我的疑问是在第一个实例中提供此功能背后的概念动机是什么？真的有人觉得这些评论有用吗？

当源镜像到外部位置（源包、源代码索引等）时，版本控制信息可能不可用。对于这种情况，此信息可能很有用。

于 2010-05-17T13:59:06.307 回答
1

所以真的，我的疑问是在第一个实例中提供此功能背后的概念动机是什么？真的有人觉得这些评论有用吗？

在一些公司，审计控制是一个大问题。审核员希望能够从事件系统跟踪到实际的代码更改。 Fixed bugs 2292 and 2230.提供从代码到事件系统的追溯。

出于同样的原因，一些公司要求将事件编号作为源代码控制更改日志注释的一部分。

于 2010-05-17T14:16:33.000 回答