Question

我有一个小团队，我想做以下事情：

我有我的行李箱，我只是称之为TRUNK

现在，TRUNK已经在生产和运行中。现在，不可避免的缺陷会出现，但是进入bugzilla并被分配给用户。

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

现在，有一天我想创建一个名为RELEASE的新构建，我希望将一些错误修复（不是全部，只是一些）合并到RELEASE中。

请注意，我并不致力于拥有TRUNK / projects / [错误修正列表]，但这是我现在拥有的，并且不仅仅对任何/所有建议开放。

有什么想法？有什么我可以做/应该做的不同？同样，我对任何/所有建议持开放态度，包括完全改变上述程序（除了使用Mercurial作为公司让我们使用的那些）

Answer 1

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

每个新发行/故障单/增强功能都会被提交到单独的分支中。

任何时候维护者想要发布新版本他都可以将所有（或者只有一些）分支合并到“默认”或者甚至是新的分支中。 “release_1_x”。

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

Answer 2

有两种方法可以做到这一点，它们不是在发布时分歧，而是当你根据你给bugfix changesets的父母做错误修复时。 “好”的方式只使用推，拉和合并。不太好的方式（它并非完全不好，但肯定是次优）被称为 cherry picking ，它有缺点。棘手的部分是，无论你是否能够通过合并将错误修正移动到RELEASE而不将所有从TRUNK移动到RELEASE中，你必须在做出改变之前做出决定。

这是一个非常完整的答案，可以解释发生了什么的类似问题：Some help with merging legacy branch in Mercurial

关键概念是，您可以将变更集合并到任何您希望但它带来的所有祖先变更集的分支中。因此，您希望修复错误，使最小的祖先。这意味着修复一个不在TRUNK中的新变更集中的错误，恰好是您添加的最新功能，而是首先hg update到您的TRUNK和RELEASE中已经存在的变更集，并且两个伟大的候选人。之一：

RELEASE和TRUNK分歧的变更集

或

引入错误的变更集

我的偏好是后者。如果在changeset 666中引入了一个错误，那么每个具有changeset 666的clone，branch和build都需要你的修复。因此，在修复它时，请执行以下操作：

  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个不同的供应商分支，并且您想看看他们是否有针对错误55的修复，您可以这样做：

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

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

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

2 个答案: