mercurial团队存储库/挑选和选择

我有一个小团队，我想做以下工作：

我有我的箱子，我就叫它箱子

现在，TRUNK是一个已经投入生产和运行的项目。现在，不可避免的缺陷出现了，但是进入了bugzilla并分配给用户

每个用户都将主干克隆到其本地存储库，进行更改并将其推送到一个目录TRUNK/projects（projects不是TRUNK的克隆，只是一个常规目录）

现在，有一天我想创建一个名为RELEASE的新版本，我想将一些bug修复（不是全部，只是一些）合并到RELEASE中

请注意，我不支持使用TRUNK/projects/[bug fixes list]，但这正是我目前拥有的，我非常愿意接受任何/所有建议

---

有什么想法？有什么我可以做/应该做的不同吗？同样，我愿意接受任何/所有建议，包括完全改变上述程序（除了使用Mercurial，因为这是公司让我们使用的）

通常的做法是创建主题分支

每个新发行/票证/增强版将提交到单独的分支机构

任何时候维护人员想要发布新版本，他都可以将所有（或仅部分）分支合并为“默认”分支，甚至是新分支，例如“release_1_x”

---

更准确地说。处理代码的开发人员仍然可以克隆存储库，然后创建本地分支，最后，在一个或多个分支提交后，将本地更改推送到一个集中的克隆（团队中的每个其他开发人员都可以从该克隆中再次拉/克隆）。

有两种方法可以做到这一点，它们在发布时不会分开，但是，当您根据父项进行错误修复时，您会给出错误修复更改集。“好”方法只使用推、拉和合并。不太好的方法（不完全是坏的，但肯定是次优的）称为樱桃采摘，它有缺点。棘手的部分是，您是否能够通过合并将错误修复移到发行版，而不将所有内容从主干移到发行版，这是您在进行更改之前必须决定的事情

下面是一个类似问题的完整答案，解释了发生了什么：

不过，关键的概念是，您可以将变更集合并到您想要的任何分支中，但它会带来所有的祖先变更集。因此，您希望修复的bug具有最小的祖先。这意味着修复一个bug，而不是您添加的最新特性TRUNK中的新变更集，而是首先，

hg update

ing到您的TRUNK和您的发行版中已经存在的变更集，这有两个很好的候选者。要么：

• 释放和中继分叉的变更集

或

• 引入错误的变更集

我更喜欢后者。如果变更集666中引入了错误，那么具有变更集666的每个克隆、分支和构建都需要您的修复。因此，在修复时，只需执行以下操作：

  hg update 666
  .. fix the bug ..
  hg commit -m "fixed bug 55" # creats changeset 999 which a new head

然后你可以这样做：

hg update TRUNK
hg merge 999

您将知道您只引入了一个变更集。稍后，当您准备发布时，您可以执行以下操作：

hg update RELEASE
hg merge 999

你又一次只得到了你想要的一个变更集

这种处理樱桃采摘（使用导出/导入或移植）的模式的优点是，您的修复在回购中只存在一次。如果您为各种挑剔的客户提供了99个不同的供应商分支机构，并且您想看看他们是否有bug 55的修复程序，那么您只需执行以下操作：

hg log -r 'descendants(999) and heads(FUSSYCUSTOMERBRANCHNAME)'

如果没有结果，则该客户没有999，因此没有变更集666中错误55的修复。当您对多个变更集（这是导出/导入和移植的结果）重新执行相同的工作时，更难验证