Mercurial hg，我做得对吗？

Question

我们正在从 CVS 转换为 Mercurial hg。

我们的基础设施是 Windows 2003/IIS6

• 每个开发人员在他们的计算机上进行开发
• 1x 开发服务器
• 1x 临时服务器
• 生产环境

这是我到目前为止所做的：

在我的计算机、开发服务器和临时服务器上安装了 Mercurial。

1. 在开发人员上创建了一个存储库。服务器。
2. 在那里导入了我们的 CVS 存储库。
3. 将该存储库克隆到我的本地计算机。
4. 将该存储库克隆到我们的临时服务器。

在过去的开发中，我们总是共享一个分支，这并不理想，但合并是如此痛苦，以至于我们从不打扰和处理它。

现在，如果我理解正确的话，我们应该这样做：

Local:

1. hgbranch myfeature1 //Start work on feature1

需要紧急修复错误，使用影响与我们的功能相同的文件

2. hg update default
3. hgbranch bugfix1 //修复错误
4. hg commit --rev bugfix1 //完成修复我们提交的错误
5. hg push --rev bugfix1 -f //-f 这里看起来很奇怪，强制创建一个新分支
6. hg update feature1 //我们返回到 feature1 上工作
7. hg commit --rev feature1 //完成工作 commit
8. hg push --rev feature1

DEV

1. hg Branch //我们看到 bugfix 和 feature1
2. hg merge --rev bugfix1
3. hg commit //提交 bugfix1
4. hg merge --rev feature1
5. hg commit //提交 feature1 //Dev master 现在是我们的 main为新开发人员准备的主干包含功能 1 和错误修复 1。

分阶段（QA 需要在测试 feature1 之前签核该重要的错误修复

1. hgcoming //我们看到新的东西
2. hg pull --rev bugfix1
3. hg merge --rev bugfix1
4. hg commit
5. //QA 测试和签核bugfix1 我们克隆到生产仓库并同步。
6. //QA 现在可以测试 feature1，我们在 bugfix1
7. hg pull --rev feature1
8. hg merge --rev feature1
9. hg commit //commiting merge feature1
10. //QA 测试 feature1 并签核
11. 我们克隆到生产存储库并同步，

这种方式是否有意义？

Answer 1

看起来您已经很好地掌握了概念，但是其中有一些奇怪的地方和一些问题，我将在下面列出它们：

1. 提交不采用 --rev 选项。它将当前工作目录作为一个新的变更集提交，其父级（如果是合并则为父级）是 hgparents 返回的任何内容，这始终是您上次 hg update 编辑到的内容。
2. 在非常新的 (1.5+) 版本的 Mercurial 中，您的 hg Push --rev bugfix1 -f 不需要 -f 。从历史上看，警告“您正在创建一个新头”通常意味着您忘记合并，但现在如果新头是一个新的命名分支，则警告将被抑制。
3. 如果我是在本地计算机上进行紧急错误修复的人，我只需创建一个新的克隆并在其中进行分支和修复。如果您设置网络服务器/网络应用程序配置以支持您可以轻松/自动地在新路径位置允许新实例
4. ，那么我认识到让他们独立于功能测试错误修复的愿望，这是一个好主意，您的QA 团队不应该合并。让/让开发人员合并，并让 QA 团队将合并修订拉入他们的工作区域。例如，在 DEV 步骤 3 中创建的开发人员变更集已经提供了错误修复和旧版本的正确集成，因此让 QA 团队拉取该修订版，该修订版将位于“默认”分支上。同样，在 QA 批准错误修复并准备好继续使用该功能后，让他们从开发中提取在开发步骤 5 中创建的变更集。

请记住，合并也是编码 - 进行合并的人正在选择应该做什么不应该是这样。质量检查人员可能有能力做到这一点，但这是开发人员的工作。另外，为什么要进行两次？通常的交接类似于“QA，拉出修订版 897a9d9f9a7 并请测试 - 开发人员”。如果你想变得更奇特，你可以有一个像“readyforQA”这样的标签，开发人员可以沿着“默认”分支移动（在这个例子中，他们在步骤 3 和 5 之后使用 hg tag让 QA 知道有新的东西需要拉动，

我给你的一条建议是不要试图过度设计 DVCS 导致一种随意的工作方式，一开始这有点可怕。 ，但你往往会发现子团队和成对的人有你从未知道的克隆，最后只要你有一些严格的规则，比如“没有首先通过质量保证，任何东西都不会进入生产”。休息一下就可以了。