Mercurial hg，我做得对吗？

时间：2010-04-21 18:54:58

标签： version-control mercurial cvs

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

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

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

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

在我的机器上，开发服务器上和登台服务器上安装了Mercurial。

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

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

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

    本地

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

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

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

        8. 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的新开发人员做好准备。

          6. 暂存（QA需要在测试feature1之前签署重要的错误修正

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

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

1 个答案:

答案 0 :(得分：4)

看起来你的概念很好，但是你有一些奇怪的问题和一些问题，我会在下面列出它们：

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

    5. 请记住，合并也是编码 - 合并的人正在做出应该和不应该做的选择。质量保证人员可能有能力，但这是开发人员的工作。另外，为什么要两次呢？通常的切换就是“QA，pull revision 897a9d9f9a7和测试请 - 开发人员”。如果你想得到想象，你可以有一个像'readyforQA'这样的标签，开发人员随着它们前往'默认'分支（在这个例子中，他们在{3}和第5步之后hg tag让QA知道有新东西要拉。

    我给你的一条建议就是不要试图过度设计这个过程。 DVCS导致了一种随意的工作方式，起初有点吓人，但往往会有所成效。你会发现子团队和一对人都有你从未知道的克隆，并且最终只要你有一些坚定的规则，例如“没有先通过QA就没有生产”，其余的工作本身就可以了。

相关问题
最新问题