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

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(这给你多头).因此,您无需创建命名分支即可将新的开发分支添加到存储库.

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

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

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

命名分支是相似的,但不同.它们允许您在每个变更集中嵌入一个命名.因此,您可以在历史记录中使用名称"foo"创建多个更改集.当你这样做时,hg update foo你将最终获得最大的变化集.通过这种方式,命名分支可以作为一种浮动标记.

如果您对更改集的永久标签的想法感到不舒服,则可以尝试书签扩展.这也将为您提供可用于更新的"浮动标记",但它们不会永久成为历史记录的一部分,因为它们没有版本化.

我希望这能有所帮助.