封闭分支如何影响Mercurial的表现?

Chr*_*ips 19 mercurial branch dvcs branching-strategy

我注意到有关分支名称的问题的一些 答案引用Mercurial wiki来指示每个功能的分支或每个bug的分支命名约定可能会导致性能问题.将分支标记为--close-branch在提交时标记为关闭的能力是否会对此性能声明产生任何影响?

Mar*_*ler 28

将分支标记为--close-branch在提交时标记为关闭的能力是否会对此性能声明产生任何影响?

标记分支hg commit --close-branch仅关闭仅close=1在变更集元数据中使用标记创建新变更集.像命令hg brancheshg heads再就知道不显示这个分支/头.这些命令使用分支缓存来加快速度,我们希望缓存能够很好地扩展分支数量.

但是,有些操作的复杂性与拓扑头的数量成线性关系.这包括1.9版之前使用的发现协议.版本1.9中的新发现协议仍将在其"样本"中交换拓扑头,但样本大小的上限为200个更改集.

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

$ hg update bug-123
$ hg commit --close-branch -m "All fixed"
$ hg update default
$ hg merge bug-123
Run Code Online (Sandbox Code Playgroud)

而是在关闭前合并:

$ hg update default
$ hg merge bug-123
$ hg update bug-123
$ hg commit --close-branch -m "All fixed"
Run Code Online (Sandbox Code Playgroud)

后一种方法在图中留下悬垂的头(拓扑头).

  • 我不知道"讨论",但你只能看到你的拓扑头:`hg heads --topo` (2认同)

Ry4*_*ase 23

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

Mercurial旨在与数百个分支机构合作.它仍然适用于万个分支,但是一些命令可能会显示明显的开销,只有在工作流已经稳定后才能看到.

MG和我(我们在你们两个链接问题中都是主要回答者)的原因是因为我们一次又一次地看到人们在得知Mercurial中的分支名称是永久性的时候会非常恼火.这是通常的交换,每周几次在IRC中自我行动:

  • 人A:"我有100个分支,我想摆脱它们!"
  • B人:"你不能.你可以隐藏它们,但Mercurial分支是永远的."
  • 答:"但是在git中,我有1000个分支,随时随地摆脱它们!"
  • B:"是的,在Mercurial中,这些被称为书签."

或类似的:

  • 人物C:"我命名了一个分支''愚蠢的功能营销使我添加',我想推动这个改变没有推动分支名称."
  • B人:"你不能.你可以将它合并为默认值,但该名称在变更集上是永久性的.你必须重新创建变更集才能摆脱它!"
  • C:"但是在git我的分支名称只是本地的!"
  • B:"是的,在Mercurial中,这些被称为书签."

如果你想在你的更改上永久保留分支名称(而MG,我在这两个问题上的合作伙伴确实就是这样),那么一定要使用它们,并且不要担心性能.但是要担心你的工具如何代表分支:就像Mercurial本身一样,工具通常是为了扩展变更集的数量,而不是分支的数量.因此,他们经常做一些天真的事情,例如将所有分支名称放入一个下拉菜单中.当命名分支变得更受欢迎时,这个GUI问题最终将得到修复.

史蒂夫·洛什(Steve Losh)出色的Mercurial分支指南可以很好地说出你的(四个!)选项.选择你喜欢的东西,并确信有很多人喜欢你选择的任何一个,并且至少有一些人拥有比你更多的分支.