我们有Mercurial版本控制系统，我们在管理强制功能，可选功能和研究的发布方面遇到了困难。我们有两个独立的存储库，一个用于发布，一个用于开发。
我们每个季度都安排了部署。因此，我们开发了三个月的功能（强制和可选），测试人员测试Dev站点上的功能（持续构建）。
在发布周期结束时，我们必须从开发回购中获取强制和可选功能（仅限QA）并手动将它们复制到发行版回购中。我们无法将开发存储库合并到发行版中，并且必须手动复制文件，因为在发布时，开发存储库中可能存在未经测试/未开发的功能/代码。然后，我们从发布存储库构建测试站点，让测试人员在那里进行全面测试。如果发现任何问题，则首先在发布回购中修复这些问题，然后将发布回购合并到开发回购中。
但是，由于手动合并，有可能将不需要的更改/文件复制到发布回购中并导致问题。
有人可以建议如何使用Mercurial摆脱这个手动复制粘贴？我确信这是开发公司的标准流程，应该有一个更好的流程来处理这个问题。
谢谢。
答案 0 :(得分：0)
您必须从发布点进行功能开发。从不在tip或从随机点：
v1 ----- v2 -- v3 --> v?
|\ // /
|\f1 ---/ /
|\f2 --- /
| f3 -------
f4 ------------------>
f...是功能开发。 v...是成功合并/测试功能集之后的分数（严格来说它是一个标记，但是为了维护发布修复，您可以使用命名分支）。
在示例中，我通过合并/测试/修复f1分支或f2分支标记为v2来为v2版本选择功能default和v2 1}}更改f1和f2分支中的内容。如果我在f1中发现错误，我会在f1中修复该错误，然后合并到v2'和v3'。
f3功能仅在v3版本中准备好发货。虽然我们仍然认为f4不适合发货。
基本部分 - 正确选择启动工具功能的点。如果您选择过早v点 - 源代码树中可能会遗漏某些功能，如果您选择太晚并且要求在早期版本v0中提供功能 - 则必须在没有支持的情况下向后移植功能来自DVCS工具。
您无法在其他功能的基础上开发功能，只能在功能关节点之上。
这与补丁管理类似，但我们尝试保留合并历史记录，因此我们有清晰的方向特征关系图，因此进一步合并会很容易。
另外，你要求避免挑选＆＃34;功能＆＃34;。该术语通常与错误挑选有关，可以通过bisect找到引入错误的第一个变更集来修复错误，修复该变更集之上的错误并合并到所有必需的修复分支。
或者像现在一样采取樱桃挑选，因为很容易采用这种有线的开发/发布模式。 SVN分支模型（特定于实现）与您使用Mercurial非常接近。