svn - 更好的发布管理策略？

Question

我在一家制作基于网络的工具的公司工作。作为我工作的一部分，我被赋予了这个产品的发布工程任务(这是我以前从未做过的)。我已经使用 SVN 设置了以下系统(抱歉，在有人建议切换到 GIT 或 perforce 或无数其他选项之一之前，我们不能使用另一个存储库!)

Trunk 是生产服务器上一直存在的东西
有 2 间分行随时营业
1) 维护版本。这是每周三发布
2)冲刺分支。这是每周发布的(星期三与那周的主分支)

在发布之前，我将那几周的分支合并到主干中。

我发现在运行 svn merge 时，它​​通常会在合并时产生大量问题。因此，我们切换到每周一次的手动合并 session ，这需要 10 分钟到 1 小时不等，我实际上将系统上的 2 个目录 winmerge 并询问每个开发人员“这是您的更改吗？我们应该使用哪个版本的代码保持？”

这个系统绝对不是理想的。

有人可以提出更好的建议吗？

Answer 1

您的 后备箱分支应该包含所有最新的开发代码，其中包括新的和未经测试的功能以及来自其他分支的任何代码。将所有代码合并到此分支中非常重要。

当您准备好(或认为您准备好)进行测试时，创建一个 稳定 从你的主干分支上分支。此分支仅用于测试和修复错误。不要在此处向您的应用程序添加任何新功能或改进，否则可能会破坏您现有代码的稳定性。不要忘记将此分支中所做的更改合并到您的主干分支中。

当您准备好发布时(您的测试已完成)，创建一个 发布 从你的稳定分支分支出来。如果在生产中发现错误/问题，这是您发布到生产和维护/支持的分支。与 stable 分支一样，不要向该分支添加任何新内容。这个分支通常被标记以便在生产中识别它。不要忘记将此分支中所做的更改合并到稳定分支中，以便从稳定分支创建的其他发布分支从所做的任何错误修复中受益。

分支层次结构如下所示:

trunk
|-- stable 1.0
  |-- release 1.0
  |-- release 1.1
|-- stable 2.0
  |-- release 2.0

使用此层次结构，您的开发团队可以在主干分支中自由开发，而 stable 和 release 分支允许维护应用程序的当前和以前版本。