Question

如果bisect范围包含多个分支，hg bisect的搜索工作如何。它是否有效地将每个子分支一分为二（我认为这样效率会很低）？

例如，感谢借用this related question答案中的图表，如果bisect首先在“好”右侧分支上改变7，该怎么办？

@  12:8ae1fff407c8:bad6
|
o  11:27edd4ba0a78:bad5
|
o    10:312ba3d6eb29:bad4
|\
| o  9:68ae20ea0c02:good33
| |
| o  8:916e977fa594:good32
| |
| o  7:b9d00094223f:good31
| |
o |  6:a7cab1800465:bad3
| |
o |  5:a84e45045a29:bad2
| |
o |  4:d0a381a67072:bad1
| |
o |  3:54349a6276cc:good4
|/
o  2:4588e394e325:good3
|
o  1:de79725cb39a:good2
|
o  0:2641cc78ce7a:good1

那么它只能看到7到12之间，错过了我们关心的真正的第一个坏处吗？（因此使用“哑”数字顺序）或者它是否足够聪明以使用完整的地形并且知道第一个坏的可能在右侧分支上低于7，或者仍然可以在左侧分支的任何地方。< / p>

我的问题的目的是（a）更好地理解算法，以及（b）理解我是否可以自由扩展我的初始二等分范围而不用考虑我去哪个分支。我一直在high-branching bisect situations，在每次测试之后它一直问我延伸到下一次合并之后，所以整个过程基本上都是O（n）。我想知道我是否可以将第一个“好”标记方式抛回到一些合并嵌套之后而不考虑它，以及是否可以节省时间并给出正确的结果。

Answer 1

引用Mercurial: The Definitive Guide：

hg bisect命令知道Mercurial的“多枝”特性项目的修订历史，所以处理没有问题存储库中的分支，合并或多个头。它可以修剪整个历史的分支用一个探针，这是怎么回事如此有效地运作。

执行工作的代码在hbisect.py中，实际上是查看已确定状态的每个节点的后代树和祖先树。

在我看来，选择测试的变更集是通过权衡“尚未测试的图表中的”中心“来选择的（即由祖先与非祖先划分，而不是按时间顺序排列）：

108     x = len(a) # number of ancestors
109     y = tot - x # number of non-ancestors
110     value = min(x, y) # how good is this test?

当范围包括分支时，mercurial的bisect如何工作？

1 个答案: