如何使用Mercurial的svnmerge工作流程？

Question

svnmerge有助于阻止特定分支的某些更改集.如何通过Mercurial实现这一目标？

Answer 1

什么subversion调用合并与Mercurial中的合并有很大不同.svnmerge或do的操作svn merge通常在其他版本控制系统中称为"樱桃选择".基本上它会创建一个新提交,它是目标分支中原始变更集的副本.在Mercurial中,可以使用移植扩展来完成.

与常规合并相比,这种方法在DVCS中不太流行,因为它创建了多个头部,这些头部难以维护.以下是如何使用它以及结果输出的样子:

$ hg checkout -r 8
$ hg branch release
$ hg transplant 10
applying 8ba2867cf974
8ba2867cf974 transplanted to 1f5920f61c94

7---8---9---A [default]
     \
      B [release]

在这里你有你的提交A来修复trunk上的bug并hg transplant释放它,创建一个新的提交B,它包含与A相同的更改,但具有不同的父项.

的另一种方法是不使用移植和修复只在发布分支检查.您将创建一个新的发布分支并在那里进行修复,然后您将发布分支合并为默认值.这看起来像这样:

$ hg checkout -r 8
$ hg branch release
... fix fix fix ...
$ hg commit -m"Make fix A"
$ hg checkout -r 9
$ hg merge release
1 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m"Merged release branch"

7---8---9---B- [default]
     \     /
      A---- [release]

这里B是合并提交.它没有与之关联的"额外"更改(除非存在已解决的冲突),并且具有将发布分支标记为在该点合并为默认值的特殊属性.只有一个实际的变更集可以修复错误 - 标记为"A"的错误 - 当然,更改本身也在默认分支中.

这种方法的优点是:

• 只有一个头.这对开发人员来说不那么容易混淆,并且给人一种很好的封闭感
• 您可以一眼看出默认包含发布中的所有错误修复
• 你可以看到发布有重要的错误修复

通常,您可以在适当的位置标记发布分支"v1.1"或其他任何内容,以便了解该发行版的来源.

这种方法的缺点是:

• 发布是如此之久以至于合并到默认值会导致冲突
• 您不希望合并到默认值的发布更改与您想要的更改混合在一起

你可以用第一个问题做很多事情 - 如果你必须维护一个非常老的分支,那么你最终会得到不同的分支.无论如何,补丁可能非常不同.

第二个问题是,例如,如果您对发布版本有一个"紧急"补丁,可以发布或解决错误,但需要更大的默认修复来解决潜在问题.在这种情况下,您必须合并发布,然后创建一个新的显式提交以"撤消"您不想要的提交.

这种做法svn merge在某种程度上实际上具有类似的优点.如果有选择地将更改从trunk更改为release,则必须记住合并的修订(假设您没有合并所有trunk).svn merge设置svn:mergeinfo属性,但跟踪这些属性可能会导致问题,而且你必须仔细检查日志,说"哦,是的,我确实将该修复合并到了发布中".

如果您在修复时将整个版本分支合并到主干,则无需记住已合并的修订版本.