Question

我们正在尝试从Subversion迁移到Mercurial，但我们遇到了一些问题。首先是一些背景知识：

所需的工作流程

我们希望在一个存储库中只有两个命名分支，stable和default。

开发在默认分支上进行。
错误修复已提交到稳定分支并合并为默认分支。
在每个Sprint之后，我们标记默认分支。
最终我们可以发布一个新版本，为此我们将一些代码（可能是最新的Sprint标记）从默认值转移到stable（update stable，merge Sprint_xyz），标记分支（{{1 }}和释放。

我们还想在我们的Jenkins构建服务器上为CI创建以下作业：

Sprint结束作业：此作业应使用Sprint_xyz标记默认
发布作业：此作业应将最新的“Sprint”标记更改为稳定分支，然后使用Release_6.0.0标记稳定并构建发布。

更多背景资料

Mercurial对我们来说是新的，但对于我们所看到的，这似乎是一种理智的方法。我们选择标记来标记发布的命名分支和克隆分支，试图使开发工作流程尽可能简单（单合并步骤，单一结账，只有几个分支来跟踪...）。

我们使用scrum并且可能（但不一定）在每个sprint之后发布一个版本，该版本可能（或不会）成为稳定分支的一部分并变成“可运送”版本。

我们遇到的问题（以及让我们怀疑我们是否正在以正确的方式接近......）如下：

我们处理默认分支（后面的穷人图上的'd'）：

tag Release_xyz

我们完成sprint并触发Sprint结束作业（使用Jenkins），其标签默认为“Sprint 1”：

d -o-o-o-o-

要发布Sprint 1，我们更新为稳定分支（'s'）并合并Sprint 1标记修订版和提交中的更改：

d -o-o-o-o-o-
           |
         Sprint 1

标记稳定并提交：

         Sprint 1
           |
d -o-o-o-o-o-
             \
s -o-o-o-o-o-o-

更新为默认值并合并稳定，因为默认值应保持稳定，提交和推送的超集：

         Sprint 1
           |
d -o-o-o-o-o-
             \
s -o-o-o-o-o-o-o-
               |
             Release 1

问题在于，当将'hgtags从's'合并到'd'时，mercurial会遇到一个冲突，该冲突使发布作业无法完成。生成的.hgtags应包含来自两个相关标签的信息。我们已经搜索了一个解决方案，并且可能会使用某些钩子和脚本自动化这些类型的合并冲突，但它看起来像是一个不必要且容易出错的黑客，以支持工作流，否则这些工作流程似乎没什么特别的。

我们的方法是否存在导致我们遇到这些问题的固有错误？
如果没有，解决这些问题的最佳方法是什么，而不必依赖脚本/钩子方法？
是否有更好的方法可以支持我们的工作流程？

Answer 1

我会选择特殊情况的钩子。您所看到的问题与Mercurial对元数据版本化的理念有关，其方式与普通存储库数据相同。这是简单而有效的，并且导致系统总体上更容易理解。但在这种情况下，它也会导致您的合并冲突。

导致合并冲突的原因相对简单。 .hgtags文件只是一个文本文件，里面有一堆行。每行包含一个哈希和关联的标记。在一个分支中，您添加了Sprint 1标记。在另一个分支中，您添加了Release 1标记。这些显示为在一个分支中将一行添加到文件的末尾，而在另一个分支中将另一行添加到文件的末尾。

然后合并两个分支。 Mercurial突然面临着一个决定。它应该走哪条线？应该两者兼顾吗？如果它是源代码，没有人为干预就没有办法告诉你。

但它不是源代码。这是一堆标签。规则应该是'如果添加的两行引用不同的标签，只需要同时使用它们'。但这并不是因为Mercurial将其视为可能是重要源代码的沼泽标准文本文件。

实际上，.hgtags文件应以相当特殊的方式处理以进行合并。实际上，添加代码可以将其处理到主线Mercurial以支持您的用例。

应该修改IMHO Mercurial，以便.hgtags文件只会在同一个标记有两个不同的哈希值时才会给出冲突警告。另一个奇怪的情况是，如果你的标签的散列不是标签出现的变化的祖先。在进行合并时，应该以某种方式调用该案例，但这并不是真正的冲突。

Answer 2

我怀疑您正在将标记的变更集从默认值合并到稳定版。如果您合并标记变更集，则在将第二个（可能还有标记！）变更集合并为默认值时，不应该出现合并冲突。

具有稳定和默认分支的Mercurial工作流程

2 个答案: