Mercurial分支具有不同的代码库

Question

我正在努力找出使用Mercurial处理我的工作流程的好方法。我在SO和其他地方已经阅读了很多相关的问题，但找不到合理的解决方案。

假设我有两个分支：

1. 默认分支我正常开发。从发布标记部署版本并用发布标记标记它们
2. 单独维护的特定客户的分支。它运行在单独的版本号上，从旧版本的应用程序中分支出来。

这两个分支现在大部分都是相同的，但已经存在一些差异。随着时间的推移，他们会分开更多。

这意味着我有4种类型的源文件：

1. Type-A ：两个分支中保持相同的文件（如果引入了更改，则两者中都应存在更改）。这些是大多数文件。
2. Type-B ：仅在默认分支中且不需要合并到客户分支中的文件
3. Type-C ：仅在客户分支中的文件，不需要合并到默认分支
4. Type-D ：两个分支中都存在的文件具有共享代码，但也包含应保持独立且特定于每个分支的代码

在默认分支上完成开发，并且常规版本主要是增量版本。但我也有这两种情况：

1. 对默认分支进行的一些更改也需要合并到客户分支（例如，需要修复/添加到两者的错误或功能）。
2. 对客户分支执行的“修补程序”，无法立即合并到默认分支，但最终需要合并。

问题是我无法找到一种相当简单，干净和安全的方式来支持这两种情况。 Mercurial没有合并时部分合并或忽略文件的概念。它合并了变更集，但它坚持要包含以前版本中引入的文件。

在这些方案中将默认值合并到客户分支或客户默认情况会强制我添加Type-B和Type-C的文件。对不需要添加到其他分支的Type-A文件进行更改（使其成为Type-D）会带来挑战。

现在显然我可以通过使用编译器定义来解决其中一些问题（从而在两个分支中保持源文件相同），手动编辑代码并在合并后手动删除文件但这不是最有效和最干净的处理这个的方法。

当然，这是一个足够普遍的工作流程，比我更聪明的人已经想到了。任何人都可以建议任何可以简化这些场景中的工作的方法或最佳实践吗？或者我的设置是否存在根本性的缺陷？

另外，Git是否更优雅地处理这些流程？

感谢。

Answer 1

我会在客户分支上进行客户要求的任何开发并将其合并为默认值。这适用于修补程序，它比从默认分支中挑选您的开发更改集更简单。合并前进而不是倒退更容易。它还消除了Type-B文件问题，因为客户分支中没有Type-B文件。

键入C文件我将合并为默认值，然后在默认分支上删除。对这些文件的任何进一步修改都应该生成一个警告，即在分支上修改的文件已在另一个分支上删除。

Answer 2

可以使用hg graft -r SRCREV命令在分支之间交换单独的变更集

更复杂，可能更硬（但也更灵活，更易于管理）的方式可能是使用MQ和多个队列（每个类型的队列？），但即使有一个具有良好命名约定的MQ补丁队列，您也不会丢失