Question

我正在使用hg来管理一些配置文件，我正在寻找一些工作流程的建议。

发布版本有两种可能的配置，例如A和B.大多数设置在两者之间是相同的，但存在一些差异。我想使用存储库，以满足这些标准：

所有历史记录都已备份（没有任何随机补丁）
更改配置A和配置B中使用的文件只能在一个地方完成（我不希望保持两个独立的文件同步）并且只需要很少的后处理（参见{{ 1}}下面的想法）
部署时可以轻松地在配置A和配置B之间切换（可能是hg graft或hg update config-a）

我已经有过不同程度的一些想法和探索：

两个单独的存储库或分支

这很好用，但意味着必须在两个独立的地方同步更改，这很烦人且容易出错。

Config A的一个主分支，以及mq处理的补丁以切换到B

我实际上并没有使用hg update config-b，互联网似乎暗示它几乎已被弃用，不应该使用，因为它有备份更改的问题。可能是这是合法使用它的情况，但我想在提交到这条路径之前得到用户的确认。

Config A的一个主要分支，历史中某个随机变更集描述了如何从A切换到B，并且每当编辑公共配置文件时，使用mq为Config B创建第二个头。

这种方法似乎有道理，但是（1）每当hg graft被应用时，历史将会被额外的头部所困扰（我无法真正剥离它们，因为它们将被发布到服务器以进行再分配），（2））每当编辑公共文件时都需要一个额外的步骤，（3）我在hg graft时没有想出如何创建一个新的分支，所以我必须记住重新更新{{1}在进行常见更改时提示，以及（4）如果修改了从A切换到B的更改集，或者获得了额外的步骤，我不清楚如何很好地跟踪“将A移动到B但是没有变化的这一系列变更集”实际上有一个头“（这句话实际上听起来很像hg graft）。

还有其他建议吗？

（请使用上面的标准来保持基于事实的答案，而不是主要基于意见[是的，添加所以它不会被关闭:-)]）

Answer 1

我在一个存储库中使用两个命名分支，它可以正常工作。我总是在同一个分支中进行常见的更改（例如＆＃34; config-a＆＃34;），然后合并到另一个分支。它涉及一些后期处理，因为你总是必须合并常见的东西，但是一旦你习惯它就不会花那么多时间，例如：

hg update config-a
<change some files>
hg commit -m "Some common config change"
hg update config-b
hg merge config-a
hg commit -m "Merge from config-a"

合并总是从a到b完成，因此b的特定更改永远不会在a中完成。但是，在进行特定于a的更改时，必须记住在合并到b（也就是＆＃34;虚拟合并＆＃34;它）时将其还原，例如：

...
hg update config-b
hg merge config-a
hg revert --all --rev .
hg commit -m "Dummy merge from config-a"

您可以手动编辑文件以使更改适应config-b，而不是执行hg revert。

编辑：根据Mercurial doc，进行虚拟合并的一种安全方法 - 并防止任何外部合并工具在发生冲突时弄乱它 - 是这样做的：

hg -y merge --tool=internal:fail config-a
hg revert --all --rev .
hg resolve -a -m

适当的mercurial工作流程，用于维护具有共享状态的两个单独配置

1 个答案: