如何将svnmerge工作流用于Mercurial？

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

subversion所称的合并与Mercurial中的合并完全不同。svnmerge或

svn merge

执行的操作在其他版本控制系统中通常被称为“cherry pick”。基本上，它创建了一个新的提交，它是目标分支中原始变更集的副本。在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]

这里有一个commit A，它修复了trunk上的bug，您将它

hg移植到release，创建一个新的commit 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是一个合并提交。它没有与之相关的“额外”更改（除非有已解决的冲突），并且具有将发布分支标记为在该点合并为默认的特殊属性。只有一个实际的变更集修复了这个bug，即标记为“A”的变更集，当然变更本身也在默认分支中

这种方法的优点是：


只有一个头。这对开发人员来说比较容易混淆，并且给人一种很好的结束感
您可以一目了然地看到，默认值包含从发布到发布的所有错误修复
你们可以看到这个版本已经修复了那个重要的bug

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

这种方法的缺点是：


版本太旧，合并为默认版本会导致冲突
您不希望合并到默认版本中的版本更改与您希望的更改混合在一起

对于第一个问题，您可以做的不多——如果您必须维护一个非常旧的分支，那么不管怎样，最终都会出现分支分叉。不管怎样，补丁可能非常不同

第二个问题是，例如，如果发布版本中有一个“紧急”补丁，该补丁覆盖或解决了一个bug，但需要在默认情况下进行更大的修复以解决潜在问题。在这种情况下，您必须合并发布，然后创建一个新的显式提交来“撤消”您不想要的提交

实际上，这种做法在某种程度上与svn merge具有类似的优点。如果您有选择地将更改从一个主干合并到另一个版本，您必须记住合并的修订（假设您没有合并所有主干）
svn merge
设置svn:mergeinfo属性，但是跟踪这些属性可以，而且您必须仔细检查日志，说“哦，是的，我确实将该修复合并到了发行版中”

如果在进行修复时svn将整个发行版分支合并到trunk，则无需记住合并了哪些修订。
能否更具体一点？Mercurial处理的整个事情与svn（整个DVCS的事情，你知道的）完全不同，因此如果你指定这样的事情，回答你的问题可能会更容易：你的存储库是如何托管的，很多人有写访问权，你通常如何合并，你想阻止什么样的事情，等等。我看不出问题中有任何含糊不清的地方。我的意思是最常见的工作流：有一个trunk，它会随着发布不时地被标记。每个版本都会产生相应的错误修复分支，即当1.0被标记时，会立即创建相应的1.0-fixes分支。当修复提交到主干时，需要根据具体情况决定是否将该修复从主干向后移植到特定的发布修复分支。svnmerge很好地实现了自动化。首先，感谢您的回答。Re：与常规合并相比，这种方法在DVCS中不太流行，因为它会创建多个头部，而这些头部更难维护——那么使用DVCS的项目如何管理版本维护分支呢？