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

发布于 2025-01-03 01:51:31 字数 394 浏览 0 评论 0原文

我注意到一些关于分支名称问题的答案引用 Mercurial wiki 来指示按功能分支或分支-每个 bug 的命名约定可能会导致性能问题。

在提交时使用 --close-branch 标志将分支标记为关闭的能力对此性能声明有任何影响吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

十六岁半 2025-01-10 01:51:31

在提交时使用 --close-branch 标志将分支标记为关闭的能力对此性能声明有任何影响吗？

使用 hg commit --close-branch 将分支标记为关闭只会在变更集元数据中创建一个带有 close=1 标记的新变更集。像hgbranches和hgheads这样的命令将知道不显示这个分支/头。这些命令使用分支缓存来加快速度，我们希望缓存能够随着分支数量的增加而很好地扩展。

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

可能还有其他代码路径仍然在头数量上线性缩放，这就是为什么我们建议 close-before-merge:

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

而不是 merge-before-close：

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

后一种方法在图中留下了一个悬空头（拓扑头）。

Does the ability to mark branches as closed with the --close-branch flag on commits have any affect on this performance claim?

Marking a branch closed with hg commit --close-branch merely creates a new changeset with a close=1 marker in the changeset meta data. Commands like hg branches and hg heads will then know not to show this branch/head. These commands use a branch cache to speed things up and we expect that cache to scale well with the number of branches.

However, there are some operations that have a complexity that is linear in the number of topological heads. This includes the discovery protocol used before version 1.9. The new discovery protocol in version 1.9 will still exchange topological heads in its "samples", but the sample size is capped at 200 changesets.

There might be other code paths that still scale linearly in the number of heads and this is why we suggest close-before-merge:

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

instead merge-before-close:

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

The latter approach leaves a dangling head in the graph (a topological head).

回复收藏 0 原文

浮华 2025-01-10 01:51:31

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

Mercurial 旨在与数百个分支机构良好配合。它仍然可以很好地处理一万个分支，但某些命令可能会显示出明显的开销，只有在工作流程稳定后您才会看到这些开销。

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

A：“我有 100 个分支，我想摆脱它们！”
B：“你不能。你可以隐藏它们，但水银树枝是永远的。”
A：“但是在 git 中我有 1000 个分支，只要我想就可以删除它们！”
B：“是的，在 Mercurial 中，这些称为书签。”

或类似的：

C 人：“我将一个分支命名为‘愚蠢的功能营销让我添加’，我想在不推送分支名称的情况下推送该更改。”
B：“你不能。你可以将它合并到默认值中，但该名称在变更集中是永久的。你必须重新创建变更集才能删除它！”
C：“但是在 git 中我的分支名称只是本地的！”
B：“是的，在 Mercurial 中，这些称为书签。”

如果你想在你的更改上使用永久的、永远的分支名称（MG，我在这两个问题上的共同回答者确实喜欢这样），那么一定要使用它们，并且不用担心性能。但请务必担心您的工具如何表示分支：与 Mercurial 本身一样，工具通常是根据变更集的数量而不是分支的数量来构建的。因此，他们经常做一些幼稚的事情，比如将所有分支名称放入一个下拉菜单中。当命名分支变得更加流行时，这个 GUI 问题最终将得到解决。

Steve Losh 的优秀Mercurial 分支指南很好地阐明了您的（四个！）选项。选择你喜欢的，并相信有很多人喜欢你选择的任何一个，并且至少其中一些人拥有比你更多的分支。

Closed branches probably won't make any difference in performance, but that's not the point. The performance implications are small, and certainly not the reason I suggested you avoid permanent branch names for short-lived lines of development. Here's the relevant quote from the wiki:

Mercurial is designed to work well with hundreds of branches. It still works quite well with ten thousand branches, but some commands might show noticeable overhead which you will only see after your workflow already stabilized.

The reason both MG and I (we're the primary answerers in both of your linked questions) is because time and time again we watch people get really annoyed when they learn that branch names are permanent in Mercurial. Here's the usual exchange, that acts itself out in IRC a few times a week:

Person A: "I've got 100 branches and I want to get rid of them!"
Person B: "You can't. You can hide them, but Mercurial branches are forever."
A: "But in git I have have 1000s of branches and get rid of them whenever I want!"
B: "Yes, in Mercurial those are called bookmarks."

or similarly:

Person C: "I named a branch 'stupid feature marketing made me add' and I want to push that change w/o pushing the branch name."
Person B: "You can't. You can merge it into default, but that name is permanent on the changeset. You'd have to re-create the changeset to get rid of it!"
C: "But in git my branch names are local only!"
B: "Yes, in Mercurial those are called bookmarks."

If you want permanent, forever branch names on your changes (and MG, my co-answerer on both of those questions does like exactly that) then by all means use them, and don't worry a bit about performance. But do worry about how your tools represent the branches: like Mercurial itself, tools are typically built to scale in the number of changesets, not the number of branches. So they often do naive things like putting all branch names into a single drop-down menu. This GUI problem will eventually be fixed when named branches become more popular.

Steve Losh's excellent Guide to Branching in Mercurial does a great job spelling out your (four!) options. Pick what you like and be confident there are plenty of folks who like whichever one you selected, and at least a few of them have more branches than you ever will.

回复收藏 0 原文

~没有更多了~