Mercurial工作流建议

我想要一些关于使用Mercurial的建议

我们目前在中央服务器上使用CVS，并维护一个head分支和几个旧版本分支。我们的工作流程是在头部实现所有修复/新功能，然后在任何分支上创建发行版时，我们将有效地拾取和选择需要包含在分支上的文件，并移动分支标记以合并这些文件，然后构建发行版（并对其进行标记）

---

我想在Mercurial中实现类似的工作流。但是，我不确定是否可以从默认分支中选择特定的修复（变更集），并将它们应用于我的一个发布分支。我所看到的是，人们将修复程序应用于他们的分支，然后将它们拉入默认分支。是否有一种方法可以使用Mercurial模拟上述CVS工作流？

这在很大程度上取决于您的“过去版本分支”实际上是什么，但我认为您在迁移时应该采用不同的工作流

把合并分支想象成合并河流：合并后，一个分支中的所有东西也都在另一个分支中。这就是为什么如果您想要实现一个应该在几个分支中结束的特性，建议的方法是在其中一个分支中实现它，然后将其合并到其他分支中。理解源分支中的所有内容最终都将位于目标分支中，而不仅仅是您实现的功能，这一点非常重要

所以有过去版本的分支来形成一个。例如，您有三个长期存在的分支：

1.x

、

2.x

和

default

。

1.x

中的所有功能也出现在

2.x

和

default

中，

2.x

中的所有功能也出现在

default

中。（这里，

default

是下一个主要版本的阶段；当您发布v3.0时，您将创建一个新的分支

3.x

。）

因此，如果您想在

1.x

中创建一个新特性，可以在那里实现它，然后进行两次合并：

1.x

到

2.x

，然后

2.x

到

默认值

（这是前向移植）。如果您尝试以另一种方式进行操作，在

default

（即后移植）中，您将无法将

default

合并到

1.x

或

2.x

，因为

default

有许多其他内容不应该出现在旧版本中。很难逆流而上，因此您必须将必要的更改移植回

1.x

和

2.x

，这很可能不会干净地应用，而且您基本上是手工完成Mercurial可以为您完成的事情

---

您可以看看Python存储库的布局，在。

中进行了解释。根据我的经验以及我对集体分布式版本控制用户体验的理解，问题在于，选择变更集是（实际上一直是）合并冲突的一个处方。从本质上讲，通过尝试在最新代码上实现更改并将其“后传”到较旧的代码，您迫使自己不得不一次又一次地重复相同的合并

假设您正在维护三个版本Head、Head-1和Head-2。在Head-1中，您实现了一个主要的重构更改。现在，您在Head中实现了三个新特性，希望将它们包括在Head-1和Head-2中。由于Head和Head-1都有相同的大重构，因此将新特性合并到Head-1中就不会那么复杂了。然而，要在Head-2中合并新特性，您可能必须解决所有三个特性之间完全相同的合并冲突，以避开主要重构

事实上，您可能已经在这样做了--您只是没有意识到这一点，因为CVS也不能帮助您在另一个方向进行合并。Mercurial和Git等较新的版本控制系统可以使“前进”方向的合并更加容易

因此，与其在Mercurial中实现Head中的三个特性，不如在Head-2中实现更改。由于合并信息已经在图形模型中捕获，因此很可能合并到Head-1，然后再合并到Head将非常容易

我并不是说你所要求的不能实现——你可以使用移植扩展来实现你的模型——如果你这样做，你就不会利用Mercurial出色的合并能力，你会为自己和你的团队做更多的工作。

在我看来，这是向前迈出的一大步从CVS到Hg。除非你在CunCH模式®中，我强烈建议你考虑改变你的工作流程，以利用HG提供的许多可能性。把它看作是从汇编语言到Python的VCS等价物。