具有不同代码库的Mercurial分支 [英] Mercurial branches with different codebase

问题描述

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

I am struggling with figuring out a good method for handling my work flow using Mercurial. I have read many related questions here on SO and other places but couldn't find a reasonable solution.

假设我有两个分支:

1. 我在其中进行常规开发的默认分支.从中部署发布并用发布标记对其进行标记
2. 特定客户的分支机构，单独维护.它在一个单独的版本号上运行，该版本号是从较早版本的应用程序分支而来的.

这两个分支现在基本相同，但已经存在一些差异.随着时间的流逝，它们会逐渐分开.

These two branches are mostly identical now but there are already some differences. Over time, they will drift apart more.

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

It means that I have 4 types of source files:

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

1. Type-A: Files that remain identical in both branches (changes, if introduced, should be present in both). These are most of the files.
2. Type-B: Files that are only in the default branch and do not need to be merged into the customer branch
3. Type-C: Files that are only in the customer branch and do not need to be merged into the default branch
4. Type-D: Files that are present in both branches, have shared code but also contain code that should remain separate and specific to each branch

在默认分支上完成了开发，并且有常规发行版，这些发行版大多是增量版.但我也有以下两种情况:

Development done on the default branch and there are regular releases which are mostly incremental. But I also have these two scenarios:

1. 对默认分支所做的一些更改也需要合并到客户分支(例如，需要同时修复/添加到两者的错误或功能).
2. 对客户分支机构的修补程序"，不能立即合并到默认分支机构，但最终需要在某个时候进行合并.

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

Problem is that I can't figure out a reasonably simple, clean and safe way to support these two scenarios. Mercurial doesn't have the concept of partial merges or ignoring files on merge. It merges changesets but it insists on including the files that were introduced in previous revisions.

在这些情况下，将默认值合并到客户分支中或将客户合并到默认值中会迫使我添加Type-B和Type-C的文件.对不需要添加到其他分支的Type-A文件进行更改(使其变为Type-D)带来了挑战.

Merging default into customer branch or customer into default in these scenarios forces me to add files of Type-B and Type-C. Making a change to file of Type-A that doesn't need be added to the other branch (making it Type-D) introduces a challenge.

现在，显然我可以通过使用编译器定义(因此在两个分支中保持源文件相同)，手动编辑代码以及在合并后手动删除文件来解决这些问题，但这并不是最有效，最干净的方法处理方式.

Now obviously I can work around some of these problems by using compiler defines (thus keeping source files the same in both branches), editing code manually and manually removing files after merges but this doesn't feel like the most efficient and clean way to handle this.

当然，这是一个足够普通的工作流程，比我已经想像的要聪明的人.在这种情况下，谁能建议任何方法或最佳实践来简化工作?还是我的设置存在根本缺陷?

Surely this is a common enough work flow that wiser people than me already figured out. Can anyone suggest any method or best practices that can streamline the work in these scenarios? Or is there something fundamentally flawed with my setup?

此外，Git是否可以更优雅地处理这些流程?

Also, does Git handles these flows more gracefully?

谢谢.

推荐答案

我将进行客户需要在客户分支上进行的任何开发，并将其合并为默认对象.这将适用于修补程序，并且比从默认分支中挑选开发变更集更简单.向前合并比向后合并更容易.由于客户分支中没有Type-B文件，因此它也摆脱了Type-B文件问题.

I would do any development that a the customer requires on the customer branch and merge it into default. This will work for hotfixes and it is simpler than cherry-picking your development changesets from your default branch. It's easier to merge forwards rather than backwards. It also gets rid of Type-B file problem because there are no Type-B files in the customer branch.

我将C型文件合并为默认文件，然后在默认分支上删除.对这些文件的任何进一步修改都应生成一条警告，指出在分支上修改的文件已在另一个分支上删除.

Type C files I would merge into default and then delete on the default branch. Any further modifications to these files should generate a warning that file modified on branch was deleted on the other branch.

这篇关于具有不同代码库的Mercurial分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！