Question

我不使用Mercurial，但我想开始，所以我正在阅读它。我广泛使用的唯一SCM系统是CVS。我所读到的关于Mercurial的大部分内容都很有意义，而且听起来不错。但是我会以这种方式感到震惊和困惑。它会标记。

标签只是变更集的昵称（而'变更集'我们实际上是指变更集产生的状态）。凉。从标记到变更集ID的映射存储在.hgtags文件中。也很酷。 .hgtags文件已版本化。

什么？的

这有很多违反直觉的后果。例如，如果我提交一个我想要标记的变更集（例如，将形成版本1.0的代码），我必须在标记后再次提交，以将更新的标记文件放入存储库。如果我稍后更新到该标记的变更集，则工作副本将不包含该标记的任何知识。如果我做了一些工作，从而建立了一个新的分支（例如，对于错误修正，朝向1.1），该分支将不知道它所生长的标记。除非我手动复制它，即。

随着开发在原始主干和我的新分支上继续进行，创建标记以标记重要的变更集（主干上的2.0版本，分支上的1.1和1.2错误修复版本），两个分支都将无知地继续其他分支的标签。所以，如果我在一个分支上完成工作，并希望切换到另一个分支上的某个特定变更集（比如说，我完成了1.2 bugfix发布，但现在必须从2.1 bugfix开始，基于2.0），我现在已经塞满了。我目前的变更集不知道2.0！

我该怎么办？

我可以请一位在2.x分支上工作的人读出2.0的实际变更集ID，然后明确地使用它，但这很可怕。
我可以命名我的分支，以及使用标签，这样我就可以跳到2.x分支的头部，从而了解新标签，然后跳回到2.0标签。假设分支与标签不同，是普遍可见的 - 就是这种情况吗？即便如此，这似乎很笨拙。
我可以在存储库外部维护一个全局hgtags文件，并使用几个钩子来获取更新的副本，覆盖本地副本，并复制提交中的任何更改。我不确定这在多用户环境中是如何工作的，开发人员正在将更改推送到共享存储库;我可能只需要hgtags文件的单独存储库。
我可以使用位于版本控制机制之外的本地标记，从而避免整个问题。与共享全局标记一样，我必须建立一种机制来在开发人员之间同步localtags文件。

这些解决方案似乎都不是很好。我该怎么办？

这里假设我在单个存储库中使用命名分支来管理分支，而不是每个分支存储库。如果我做后者，情况会好转吗？

Answer 1

对.hgtags文件进行版本控制可以

编辑标签，看看谁编辑了这些标签（以及为什么他们留下了正确的提交信息）
使用常规机制在存储库之间传输标记

然而，这里有一些混乱。

你写的那个

[...]如果我稍后更新到该标记的变更集，则工作副本将不包含该标记的任何知识。 [...]

这是错误的，标签是从所有头中找到的.hgtags文件中收集的。这意味着您可以更新为旧标记（hg update 0.1）并仍然可以看到所有标记（hg tags）。
您询问分支是否普遍可见。是的 - 命名分支的名称可以在您需要指定变更集的任何上下文中使用，也可以像标记一样使用。

确保在开始使用它们之前了解命名分支的内容。它们实际上不是制作bugfix分支所必需的。您可以选择简单地返回（hg update 1.0）并修复错误然后提交。这将创建一个新的头，你的发展线向1.1（这给你multiple heads）。因此，您无需创建命名分支即可将新的开发分支添加到存储库中。

具有多个头部完全等同于具有多个克隆。你甚至可以来回转换：你可以使用

% hg clone -r X-head repo repo-X

从X-head中的其他变更集中解开repo变更集及其祖先。您可以通过简单地将所有变更集拉到一个大克隆中来组合多个克隆。

Named branches是相似但又不同的。它们允许您在每个变更集中嵌入一个命名。因此，您可以在历史记录中使用名称“foo”创建多个更改集。当您执行hg update foo时，您将最终获得最常见的变更集。通过这种方式，命名分支可以作为一种浮动标记。

如果您对更改集的永久标签感到不安，可以尝试使用bookmarks extension。这也将为您提供可用于更新的“浮动标签”，但由于它们未进行版本控制，因此它们不会永久成为历史记录的一部分。

我希望这有点帮助。

Answer 2

标记方法的选择肯定有一些奇怪的副作用，但它们在this wiki中得到了很好的解释。还建议您克隆整个仓库，然后更新到感兴趣的点，以避免您将创建一个不包含用于创建它的标记的仓库。

我怎样才能始终了解Mercurial中的所有标签？

2 个答案: