Jam*_*man 1 version-control code-comments keyword-expansion
我注意到我们系统中的一些源文件存在差异,其中一些包含源代码控制签入注释,而另一些则没有.签入时,这些注释会自动添加到文件顶部:
* $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关键字替换),但是我想知道它是否也可用于一些比较流行的DVCS.
一如既往,非常感谢您的帮助.
你是对的 - 总的来说,这不是修订控制系统的一个非常有用的功能!是的,公司喜欢审计跟踪,但这是由修订控制系统的日志命令提供的; 是的,这意味着如果修订控制系统没有,那么日志是可用的 - 但在这种情况下,Fixed bug 1234可能不是很有意义:-)而且,正如你所说,为了将更改与特定的行绑定,你还需要修订控制系统的帮助.
你也是正确的,在提交文件时更改文件可能会引起问题 - 我曾经看到一个问题,一位同事仔细确保他的代码编译,然后承诺,只是因为他提交的文件没有被玷污编译.事实证明,评论是这样的Clean up /tmp/*.txt,并且C编译器将其/*视为注释开始字符(并且抱怨因为它已经在评论中).
登录文件的另一个问题是它们只对线性工作有意义 - 一旦你用多个分支开发(就像git/mercurial/bazaar鼓励的分布式源工具的方式),只有源文件本身的日志服务几乎在所有时间都创建合并冲突.
因此,现代工具往往不实现此功能.事实上,颠覆并没有 - 它的关键字替换故意不允许包含日志历史.