3

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

所需的工作流程：

我们希望在一个存储库中只有两个命名分支，稳定和默认。

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

我们还希望在我们的 Jenkins 构建服务器上为 CI 做以下工作：

  • End-of-Sprint 作业：此作业应使用 Sprint_xyz 之类的默认标记
  • 发布作业：此作业应将最新的“Sprint”标记更改带到稳定分支，然后使用诸如 Release_6.0.0 之类的标记稳定并构建发布。

更多背景：

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

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

我们遇到的问题（这让我们怀疑我们是否以正确的方式解决这个问题......）如下：

我们在默认分支上工作（下面的穷人图上的“d”）：

d -o-o-o-o-

我们完成一个 sprint 并触发一个 End-of-Sprint 作业（使用 Jenkins），其标签默认为“Sprint 1”：

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

为了发布 Sprint 1，我们更新到稳定分支 ('s') 并合并来自 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

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

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

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

  1. 我们的方法是否存在固有的错误导致我们遇到这些问题？
  2. 如果不是，那么在不依赖脚本/挂钩方法的情况下解决这些问题的最佳方法是什么？
  3. 有没有更好的方法可以支持我们的工作流程？
4

2 回答 2

3

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

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

然后合并这两个分支。突然，Mercurial 面临一个决定。应该走哪条线？应该两个都带吗？如果是源代码，如果没有人为干预，真的没有办法分辨。

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

确实，.hgtags应该以一种相当特殊的方式处理文件以进行合并。将处理这种方式的代码添加到主线 Mercurial 中以支持您的用例实际上可能会很好。

恕我直言，应修改 Mercurial，以便.hgtags仅当同一标签有两个不同的哈希值时，该文件才会给您一个冲突警告。另一种奇怪的情况是，如果您的标签的哈希值不是该标签出现的更改的祖先。在进行合并时应该以某种方式调用这种情况，但这并不是真正的冲突。

于 2013-03-19T19:02:32.253 回答
2

我怀疑您正在将标记的变更集从默认合并到稳定。如果您合并标记变更集，则当您将第二个（可能也是标记！）变更集合并回默认值时，您不应该遇到合并冲突。

于 2013-03-19T15:06:12.997 回答