关闭Mercurial分支的最佳方法是什么？

Question

首先关闭分支然后将其与默认分支合并(例如)或首先将其合并然后关闭它是否更好？

例如,在TortoiseHg中,在第一种情况下,您将看到从关闭节点到默认分支的行.在第二种情况下,您将看到从最后一次提交到默认分支的一行以及从最后一次提交到关闭节点的额外行.

我希望我很清楚.也许这是一个品味问题......

Answer 1

这不是品味问题,而是有区别的.简而言之,关闭分支,然后合并.

对于每个变更集,Mercurial分支名称仅仅是"元数据".它确实会影响某些命令的结果,例如hg branches省略关闭的命令,或者hg push默认情况下不允许每个分支添加新的头部.但同样 - 它正在过滤.

在内部,Mercurial将存储库视为变更集的图形,DAG是特定的.并且该图的拓扑头用于逻辑实现,例如在比较本地和远程存储库期间hg pull.更多的拓扑头可以(略微但仍然)影响性能 - 封闭分支如何影响Mercurial性能？.其中一定数量的400 Bad RequestMercurial可以在IIS服务器中运行 - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling.

当第一个合并然后关闭时,分支就会关闭 - 好吧,人类默认情况下看不到那个分支.但是,mercurial获得了另一个拓扑头.请看下面的视觉解释.因此先关闭.

close then merge                merge then close
----------------                ----------------

@    default, head              @    default, head
|                               |
o    merge              <-->    | x  close branch, head
|\                              | |
| x  close branch       <-->    o |  merge
| |                             |\|
o |  dev on default             o |  dev on default
| |                             | |
| o  dev on branch              | o  dev on branch
| |                             | |
| o  open branch                | o  open branch
|/                              |/
o    default                    o    default

您可以在这里查看我们如何得出这个结论的详细信息.

Answer 2

在讨论命名分支时,这两种方法之间没有真正的区别,至少在任何最新版本的Mercurial中都是如此.事情是不同的预先1.5,但纯粹的事实,(？)hg heads和hg branches将包括它们的输出,这些"关闭"分支-他们仍然可以,如果你指定-c的命令.

请记住,当你关闭一个分支(使用hg commit --close-branch或在Tortoise中)时,你实际上只提交了一个新的变更集,其中变更的标志设置为分支X已关闭 - 您可以轻松更新到分支并通过执行另一个分支重新打开它承诺.

但是,当重新打开分支时,您在Tortoise中看到的"条形图"仍将存在于之前关闭的变更集中,因此仅此一点,我个人会选择紧密合并策略.我认为,看起来你正在从你喜欢的事物中融合(因此在合并之前关闭了分支),这在视觉上更有启发性.

"匿名"分支的情况略有不同,因为它们在hg branches合并后不会包含在输出中,因此不需要显式关闭.