我能在Mercurial分支和合并方面比我做得更好吗'；我目前正在做，或者mercurial能做得比它在这个示例测试用例中做得更好吗？

在商业开发中的版本控制中，一个项目通常有多个分支。在我的mercurial管理的项目中，我通常有一个稳定的主干版本，它是从一些常见的父级继承而来的，如下所示：

      V8     (the parent of both V8-stable and V9, revisions 1..100)
       |
       +---  V8_stable  (bug fix branch, revisions 101 to 500 )
       |
       +---  V9_trunk   (trunk, revisions 501 to 1000 )

上述所有版本的项目都有一个文件，我们称之为

helloworldapp.py

。这些示例是用Python编写的，因为它是我所知道的最像伪代码的语言，但问题不是Python问题。现在，在mercurial中，您可以使用克隆进行分支，也可以使用mercurial内置的分支功能。在本例中，我使用整个存储库的克隆进行分支

下面是V8

helloworldapp.py

，它是通用的父版本：

# helloworldapp.py rev 100 (v8)
def func1(a,b,c,d,e):
    print "stuff"
def func2(a,b,c,d,e):
    func1(a,b,c,d,e)
def func3(a,b,c,d,e):
    func2(a,b,c,d,e)
def func4(a,b,c,d,e):
    func3(a,b,c,d,e)
def func5(a,b,c,d,e):
    func4(a,b,c,d,e)
def func6(a,b,c,d,e):
    func5(a,b,c,d,e)
def func7(a,b,c,d,e):
    func6(a,b,c,d,e)

func7(1,2,3,4,5)

这是修订版500，V8稳定分支的一部分：

# helloworldapp.py rev 500 (v8_stable)
def func1(a,b,c,d,e):
    print "stuff"

def morestuff():
   print "morestuff"

morestuff()
func1(1,2,3,4,5)

以下是V9主干分支的修订版1000部分：

# helloworldapp.py rev 1000 (v9_trunk)
def func1(a,b,c,d,e):
    print "stuff"

def func4(a,b,c,d,e):
    morestuff()
    morestuff()
    morestuff()
    func1(a,b,c,d,e)

def morestuff():
   print "hello"

func4(1,2,3,4,5)

上述文件是一个非常简短的例子，说明了在面向文件的版本控制中，分支不同步时会发生的情况，当我必须管理“稳定到主干”的合并时（通过拉合并）

以下是合并时的最终情况。请注意，在现实世界中，我通常会将问题放大100倍到1000倍。在数百个文件中，我经常会遇到hgmerge无法解决的5000多行冲突，这需要我在KDiff3中手动合并每一行

除了不让分支失去同步之外，Mercurial用户还能做些什么来简化这种情况下的合并？在我上面演示的情况下，“在文件分支A上的第6行工作”与“在文件分支B上的第6行工作”是相同的，逐行合并会产生合并冲突，其中两个用户实际上（在他们自己的心目中）在一个文件中处理不同的函数。通过从一个文件中删除一个不再使用的函数（因为它不再需要），您现在几乎可以确保更多发生合并冲突的机会。您几乎必须制定规则，如“永远不要移动或删除上游稳定分支中的行”。我知道，如果您使用的是Smalltalk基于图像的版本控制系统，那么“what line is on”这一意外事件将不再发生。如果Mercurial使用的diff工具理解Python，那么它可以在Python代码方面做得更好，但代价是它可能无法在C代码上很好地工作。这就是基于文件的编程和DVCS工具的最新技术。好的

因此，在图中的合并情况下

（）

* 我看到的是合并冲突，我希望它能找出我想要全部或不想要“morestuff”函数：

我希望得到的（自动）：

我在bitbucket上发布了示例存储库，如下所示：

---

要尝试这个“我可以构造的最简单的示例，当您试图解决合并冲突时会发生什么”，请克隆上面的一个，然后从另一个中提取，然后合并。最后我的问题是：Mercurial的专业用户如何处理这种情况？请理解，这个示例是人为设计的，但显示了DVCS工具用户遇到的一些复杂性，但在现实世界中，这些冲突往往比我在这里展示的简单案例复杂得多。我已经学会了使用TortoiseHG和KDIFF3相当快地处理大多数小而简单的冲突，但是我发现合并地狱的问题比我记忆中的Subversion或Perforce要小得多，但我仍然不认为（a）程序员（我）或（b）我的工具已经做了所有可以做的事情来帮助管理和理解这种复杂性。我有一种感觉，使用Mercurial的替代解决方案、工具和工作策略存在，但我还没有尝试或了解。也许是MQ和Rebase？

事实上，根据我的经验，现实世界通常不是这样的，原因有两个：

我们更频繁地进行合并（在您的示例中是从v8到v9），以便Mercurial逐渐了解如何在两个分支之间进行整合。500个变更集是一个步骤中要拼凑起来的大量变更（我以前也这样做过！）

当合并我们的分支时，我们的更改不会像您的示例那样激烈冲突。通过减少冲突和增加每次更改的上下文，合并工具可以更好地将它们组合在一起

我们确实有碰撞，需要找出如何手动将它们组合在一起，如果我们推迟，这可能是一个很大的难题。但是，一旦我们这样做了，现在的共同祖先就是合并，我们不需要再次讨论冲突。通过更频繁地合并，可以减少自公共祖先以来的变更集数量

我有兴趣重新运行您的示例，定期将V8_-stable合并到V9_-trunk。如果您在函数def之间添加一些文本，为hg提供更多的上下文来区分更改，我也会感兴趣

---

---

尝试与您的示例进行更频繁的合并后，效果不是很好。如果您的版本差异如此之大（只有15%-25%相同），它们将成为根本不同的代码基，合并也就没有意义了。在这一点上，我尝试将这些片段分解成单独的文件，以允许两个版本（以及我的理智！）和平共存。

这几乎就像我们需要一个.hgnomerge文件来与.hgnore一起使用一样。因为重命名文件只是为了工作。当分支不同时，版本控制系统应该停止尝试合并某些文件。有一些事情需要处理-尝试读取

hg help mergetools

和

合并模式

和

合并工具

部分

hg help hgrc

。可用的工具之一是

i