关闭的分支如何影响Mercurial性能？

我注意到，对于分支名称的问题，如果使用“每特性分支”或“每缺陷分支”命名约定，可能会导致性能问题。在提交时使用

--close branch

标志将分支标记为关闭的功能是否会对该性能声明产生任何影响

关闭分支可能不会对性能产生任何影响，但这不是重点。性能影响很小，这当然不是我建议您为短期开发线避免使用永久分支名称的原因。以下是维基上的相关引用：

Mercurial设计用于与数百个分支良好协作。它仍然可以很好地处理一万个分支，但是一些命令可能会显示出明显的开销，这只有在工作流稳定之后才能看到

MG和我（我们是你两个相关问题的主要回答者）之所以这样做，是因为我们一次又一次地看到人们在得知Mercurial中分支名称是永久性的时非常恼火。以下是通常的交换，每周在IRC中进行几次：

• 人甲：“我有100根树枝，我想把它们除掉！”
• 人乙：“你不能。你可以把它们藏起来，但变化无常的树枝是永远的。”
• 答：“但在git中，我有1000个分支，我想什么时候就什么时候把它们去掉！”
• B：“是的，在Mercurial中这些被称为书签。”

或类似地：

• 人员C：“我将一个分支命名为‘愚蠢的功能营销让我添加’，我想在不推分支名称的情况下推动这一变化。”
• 人员B：“您不能。您可以将其合并为默认名称，但该名称在变更集上是永久性的。您必须重新创建变更集才能将其删除！”
• C:“但在git中，我的分支名称仅为本地名称！”
• B：“是的，在Mercurial中这些被称为书签。”

如果你想在你的变更中使用永久性的分支名称（我的这两个问题的共同回答人MG就是这么做的），那么一定要使用它们，不要担心性能。但请务必担心您的工具如何表示分支：与Mercurial本身一样，工具通常是按照变更集的数量而不是分支的数量来扩展的。所以他们经常做一些幼稚的事情，比如把所有的分支名称放到一个下拉菜单中。当命名分支变得越来越流行时，这个GUI问题最终会得到解决

史蒂夫·洛什的《优秀》很好地阐述了你的（四个！）选择。选择你喜欢的，并且要有信心，无论你选择哪一个，都会有很多人喜欢，而且至少有少数人拥有比你以往任何时候都多的分支机构

在提交时使用

--close branch

标志将分支标记为关闭的功能是否会对该性能声明产生任何影响

用hg commit标记分支关闭--close branch只会在变更集元数据中创建一个带有

close=1

标记的新变更集。像

hg branchs

和

hg heads

这样的命令将知道不显示该分支/头。这些命令使用分支缓存来加快速度，我们希望该缓存能够很好地随分支的数量扩展

然而，有些操作的复杂性在拓扑头的数量上是线性的。这包括1.9版之前使用的发现协议。版本1.9中的新发现协议仍将在其“样本”中交换拓扑头，但样本大小限制为200个变更集

可能还有其他代码路径仍然以头数线性扩展，这就是为什么我们建议在合并前关闭：

$ hg update bug-123
$ hg commit --close-branch -m "All fixed"
$ hg update default
$ hg merge bug-123

而是在关闭前合并：

$ hg update default
$ hg merge bug-123
$ hg update bug-123
$ hg commit --close-branch -m "All fixed"

---

后一种方法在图中留下一个悬垂的头部（拓扑头部）。

回答得很好，我完全同意这里给出的建议。非常感谢！我非常了解我们可以使用的不同分支模型，我主要只是好奇封闭分支是如何或是否影响了许多分支的性能声明。太棒了。你能给我指出一些进一步讨论拓扑头的东西吗？我们通常在合并之前先关闭，但偶尔会关闭一个从未关闭过（但可能已合并或未合并）的旧分支，并将头部留在那里。有什么特别的问题吗？我不知道“讨论”这个词，但是你可以通过这样做只看到你的拓扑头：

hg-heads--topo