Mercurial hg,我做得对吗？

Question

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

我们的基础架构是Windows 2003/IIS6

• 每个开发人员都在他们的计
• 1xDevelopement服务器
• 1xStaging服务器
• 生产环境

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

在我的机器上,开发服务器上和登台服务器上安装Mercurial.

1. 在dev上创建了一个存储库.服务器.
2. 在那里导入我们的CVS存储库.
3. 将该存储库克隆到我的本地计算机.
4. 将该存储库克隆到我们的登台服务器.

对于过去的发展,我们总是分享一个分支,不理想,但合并是一种痛苦,我们从不打扰和处理它.

现在,如果我理解正确,我们应该这样做:

本地:

1. hg branch myfeature1 //开始使用feature1

需要紧急修复错误,使用影响SAME文件作为我们的功能

2. hg更新默认值
3. hg branch bugfix1 //修复bug
4. hg commit --rev bugfix1 //我们提交的修复错误
5. hg push --rev bugfix1 -f // - f在这里看起来很奇怪,迫使创建一个新的分支
6. hg update feature1 //我们回到feature1上工作
7. hg commit --rev feature1 //完成工作提交
8. hg push --rev feature1

DEV

1. hg branches //我们看到了bugfix和feature1
2. hg merge --rev bugfix1
3. hg commit //提交bugfix1
4. hg merge --rev feature1
5. hg commit // commiting feature1 // Dev master现在是我们的主干,为包含feature1和bugfix1的新开发人员做好准备.

暂存(QA需要在测试feature1之前签署该重要的错误修正

1. hg incoming //我们看到了新的东西
2. hg pull --rev bugfix1
3. hg merge --rev bugfix1
4. hg commit
5. // QA测试和签核bugfix1我们克隆到生产仓库并进行同步.
6. // QA现在可以测试我们在bugfix1之后几天完成的feature1
7. hg pull --rev feature1
8. hg merge --rev feature1
9. hg commit //提交合并功能1
10. // QA测试功能1和签收
11. 我们克隆到生产仓库并进行同步.

这种方式有意义吗？我是不是让事情变得复杂,以后会不会惹恼我？

Answer 1

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

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

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

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