如何处理Mercurial中封闭的拓扑头? [英] How do I deal with closed topological heads in Mercurial?

问题描述

尝试在基尔恩(Kiln)和

While trying to work out an integration between Kiln and Bamboo I ran into an issue that Fog Creek support indicated might be a problem of having too many topological heads in my repository. We typically have a pattern of closing a branch prior to merging back into a main branch but that clearly gets forgotten from time to time.

$ hg head -t | grep ^changeset: | wc -l
1361

我的理解是，当从托管的Mercurial服务器中拉出这些头时，需要以一种或另一种方式进行通信，以了解需要同步哪些头.鉴于其中有1100个以上的头已经完全死给我们了，这真是浪费了很多精力-所以我想摆脱这些头！

My understanding is that those heads need to be communicated one way or the other when pulling from the hosting Mercurial server to know which heads need to by sync'd. That's a lot of wasted effort given that over 1100 of those heads are completely dead to us -- so I'd like to get rid of those heads!

确定要消除的头​​很简单:

It's fairly straightforward to identify the heads I want to eliminate:

$ hg log -r "heads(all()) - ( head() and not closed() )" --template "{node}\n" | wc -l
1199

我最初以为清理起来很简单:

I initially thought it would be fairly straightforward to clean this up:

1. 创建一个新的虚拟分支
2. 将所有封闭的拓扑头迭代合并到虚拟分支(保持局部)

不幸的是，我遇到了两个问题:

Unfortunately, I ran into a couple of issues:

• 如果我从当前的默认头开始创建虚拟分支，那么合并将花费很长时间(我估计完成所有1100多次合并将需要数周的时间)
• 如果我从变更集0开始，我很快就会遇到一个模棱两可的合并问题，我不知道该如何解决(模棱两可的合并-选择了m动作"?)

关于我应该如何进行的任何想法或建议?我的迭代合并想法是否理智?从何处着手的两个想法之一是否比另一个更合理?

Any ideas or suggestions on how I should proceed? Is my iterative merge idea sane? Are one of the two ideas for where to start from more reasonable than the other?

任何帮助将不胜感激！

推荐答案

执行无操作合并的最快方法是通过hg debugsetparents.例如:

The fastest way to do a no-op merge is via hg debugsetparents. For example:

hg update REV1
hg debugsetparents . REV2
hg commit -m "No-op merge"

请注意，debugsetparents之后的.不是错字，而是指当前结帐的父项.另外，请注意，hg debugsetparents允许您对直接祖先执行伪合并"，这通常是合并所不允许的.尽管此应该对Mercurial本身没有任何有害影响，但是与存储库交互的其他工具可能会造成混淆，因此您应该避免误用hg debugsetparents，因为一个父修订版是另一个修订版的祖先.

Note that the . after debugsetparents is not a typo, but refers to the parent of the current checkout. Also, note that hg debugsetparents allows you to perform a pseudo-"merge" against a direct ancestor, which is not normally allowed by a merge. While this should not have any harmful effects for Mercurial itself, other tools that interact with the repository may be confused, so you should avoid misusing hg debugsetparents where one parent revision would be an ancestor of the other.

第二，请注意，使用--close-branch关闭已合并的分支通常没有什么意义.实际上，closed标志仅由hg branches使用，并且您可以使用hg branches --active和hg branches -a淘汰没有活动头的分支(类似地，head() and heads(all()) and not closed()作为所有不活动的分支头的修订版)或关闭).因此，一个更简单的解决方案可能是摆脱所有仅存在于闭合分支中的拓扑头.

Second, note that there is usually little point in using --close-branch to close already merged branches. The closed flag is in practice only used by hg branches, and you can use hg branches --active and hg branches -a to elide branches that have no active heads (similarly, head() and heads(all()) and not closed() as a revset for all branch heads that aren't active or closed). Therefore, a simpler solution may be to get rid of all those topological heads that exist only to close branches.

这篇关于如何处理Mercurial中封闭的拓扑头?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！