mercurial - 应该如何将 svnmerge 工作流与 Mercurial 一起使用？

Question

svnmerge 有助于阻止来自特定分支的某些变更集。 Mercurial 如何实现这一目标？

Answer 1

Subversion 所称的 merge 与 Mercurial 中的 merge 完全不同。 svnmerge 或 svn merge 的操作do 通常在其他版本控制系统中被称为“樱桃选择”。基本上它会创建一个新提交，它是目标分支中原始变更集的副本。在 Mercurial 中，可以使用 transplant extension 来完成.

与常规 merge 相比，这种方法在 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 修复了主干上的错误，你 hg transplant它释放，创建一个新的提交 B，其中包含与 A 相同的更改，但具有不同的父项。

替代方法 是不使用移植并只 checkin 对发布分支的修复。您将创建一个新的发布分支并在那里进行修复，然后将发布分支 merge 到默认分支中。那看起来像这样:

$ 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 是一个 merge 提交。它没有与之相关的“额外”更改(除非解决了冲突)，并且具有将发布分支标记为此时 merge 为默认值的特殊属性。只有一个实际的变更集可以修复该错误——标记为“A”的那个——当然，这些变更本身也在默认分支中。

这种方法的优点是:

只有一个头。这对开发人员来说不那么令人困惑，并且提供了很好的封闭感

您可以一目了然地看到默认包含版本

中的所有错误修复。

你可以看到 release 有重要的错误修复

通常，您会在适当的位置标记发布分支“v1.1”或其他任何内容，以便您知道该发布的来源。

这种方法的缺点是:

版本太旧以至于 merge 到默认值会导致冲突

您不想 merge 到默认版本中的更改与您确实想要的更改混合在一起

对于第一个问题，您无能为力 - 如果您必须维护一个非常旧的分支，那么无论如何您最终都会有分歧的分支。无论如何，补丁可能非常不同。

例如，如果发布版本有一个“紧急”补丁可以解决或解决错误，但需要对默认值进行更大的修复以解决潜在问题，则会出现第二个问题。在这种情况下，您必须 merge 发布，然后创建一个新的显式提交来“撤消”您不想要的提交。

这种做法其实和 svn merge有类似的好处。在某种方式。如果您有选择地将更改从主干 merge 到版本，您必须记住您 merge 的修订(假设您没有 merge 所有主干)。 svn merge设置 svn:mergeinfo 属性，但跟踪这些可以 cause problems ，另外您必须仔细检查日志以说“哦，是的，我确实将该修复程序 merge 到了发布中”。

如果在修复时将整个发布分支 svn-merge 到主干，则无需记住已 merge 哪些修订版。