文件历史记录：在源代码中还是让scm处理它？

Question

我正在学习mercurial作为我的solo scm软件。使用其他管理软件，您可以通过标记将更改注释放入文件头。使用hg，您可以对更改集进行注释，但这不会进入源代码。我更习惯像VSS那样集中控制。

为什么要将文件历史记录放入源文件的标题中？我应该让mercurial用我的变更集评论管理历史记录吗？

Answer 1

让源控制系统处理它。

如果您在标题中添加更改详细信息，它很快就会变得笨拙并且压倒实际代码。

此外，如果scm具有更改列表的概念（其中许多文件被分组为单个更改），那么您将能够编写注释以使其适用于整个更改而不仅仅是一个文件中的编辑（如果这有意义的话），让您更清楚地了解为什么需要编辑。

Answer 2

是;让源代码管理系统处理您的变更集注释。这样做的理由是，当您稍后查看更改日志时，尝试找出文件的两个版本之间正在发生的事情时，它会更有意义 - 源控制系统可以提供更改注释以尝试启发情境

Answer 3

当SCM软件更适合解决此问题时，没有理由手动维护文件历史记录。我常常在源代码中看到部分完成的文件历史，这实际上很痛，因为人们错误地认为它是准确的。

Answer 4

不同之处不在于它是集中式还是分布式VCS，更多的是关于更改的内容。

当我转移到.Net时，针对任何个别更改而更新的文件数量似乎都在飙升。如果我必须在每个文件中记录更改，我将永远不会完成任何实际工作。通过评论一组更改，我必须更新多少文件并不重要。

如果我需要识别特定更改的所有更改，我可以在项目的两个版本之间进行区分。

我在切换SourceSafe时看到的最大区别（和优势）是从基于文件的提交切换到基于项目的提交。一旦我习惯了，我就停止在我的所有文件中添加更改日志类型注释。

（作为副作用，我发现我的流程描述评论已经变得更好了）

Answer 5

我不是支持使用更改注释乱丢代码的大力支持者。如果需要它们，可以在SCM中查找（至少对于我使用过的SCM变体）。如果你确实想要它们在文件中，请考虑将它们放在最后而不是开头。这样，在进入实际代码之前，您不必向下滚动（至少对我不感兴趣）注释。

Answer 6

让SCM系统处理签到评论的另一次投票，但我确实有一件事需要补充。

某些系统允许您在源代码中使用RCS标记，其中SCM可以将更改历史记录直接插入到自动提交的源文件中。听起来很平衡，因为历史记录在SCM系统中，然后自动放入源代码本身。

问题是此进程更改源文件。我认为这是个坏主意，因为在插入注释之前，无法在磁盘上更改文件。如果您是一名优秀的工程师，那么您应该在提交之前构建并测试更改。如果你的源在提交后发生了变化，那么你基本上就可以打破一个可能被破坏的构建 - 但是大多数工程师在提交后都不会构建 - 为什么要这样做呢？

但这只是你说的评论！没错，但我确实有一个案例，我的源文件中有代码，奇怪的是有理由看起来就像一个RCS标头标签，并且代码的那一部分在checkin上被替换，从而改变了我的代码。容易修复，但是对于20多个用户来说，构建被破坏了很糟糕

Answer 7

更容易忘记在源代码中维护历史记录，因为总是（imo）应该对源代码控制系统的提交进行评论。此外，如果在提交之前更改大量文件，则更改每个文件中的历史记录将是烦人的工作。这实际上是scm的一个要点。

Answer 8

我有这方面的经验。我在评论中有文件历史记录，它是糟糕的。除了垃圾之外什么都没有，有时候你需要向下滚动几乎1k行的代码更改才能达到你想要的效果。更不用说，通过在源代码树中添加更多kb来减慢构建过程的其他方面。