如何设置SVN仓库进行紧急修复？

Question

作为一名开发人员多年来，这是我应该知道的，但不是。

我正在一个小团队中发布一个已发布的产品。我是提交大部分代码的主要开发人员，但还有一些其他开发人员不时提交。目前，我们有一个运行Hudson CI的登台服务器，它在每次提交后构建。当主干稳定并经过测试时，通过简单的svn up命令手动更新生产。

这一般情况下工作正常，但是当代码未在主干中最终确定时，我们确实有需要紧急/紧急更改生产的情况。

如何设置回购以适应这种情况？我认为this response是一个很好的回复，但它仍然有点过头了。

我在想，在更新生产时，在该版本中创建一个分支。但是，如果我需要进行紧急生产修复，我该如何访问该分支，如何通过从该分支而不是中继来更新生产？如何确保生产分支的任何紧急修复也已提交到主干？

即。这是我希望有更好的解决方案的情况，因为它发生了几次

• Rev 1000在生产时更新
• Rev 1001-1005是新功能请求/错误修复，将包含在下一版本中
• Rev 1006是一个需要推向生产的紧急修复
• Rev 1007-1009是更多功能更新
• Rev 1010应该是更新为生产的下一个修订

更新

在阅读完SVN Book的分支部分后，我正在考虑以下设置。

1. 准备推送到prod时创建分支

   svn copy /trunk /branches/production_01 -m 'Production release'

2. 在生产时，切换到生产分支

   svn switch /branches/production_01

3. 如果需要紧急修复，开发人员需要在分支中进行更改：

   svn checkout /branches/production_01
// make changes
svn merge /trunk # make sure changes get merged into trunk as well
svn commit -m 'Urgent fix

4. 在制作时，更新到最新的分支

   svn update

这个过程听起来像我们的设置吗？

Answer 1

每次为了准备发布到生产而创建一个新分支是必要的，在大型团队中，当您试图稳定此版本时，人们仍然希望为将来的版本检查新功能。除非您一次支持多个生产版本，否则对于小型团队来说这不是必需的。

在你的情况下，我会保留一个永久production分支。每当您执行正常发布时，请在trunk中将其稳定，将trunk合并到production，然后从那里进行测试和推送。

对于修补程序，请从production ¹ 创建一个新分支，在那里进行更改，然后将其合并到production和trunk。与正常版本一样，您可以从production进行测试和推送。

---

¹ 始终从您要合并的最旧分支分支回来。它使合并更加清晰。

Answer 2

解决这个问题有不同的方法，但我认为我看到这个问题最有效的方法如下：

• 所有开发人员都进入分支机构，无论是错误修复还是新功能。这些分支位于CI下，并部署在自己的环境中进行测试。
• 要进入生产的代码从分支（错误修复分支或功能分支）合并到主干。主干也在CI下。一旦经过测试批准，它就可以转移到预先生产，然后生产。只有来自主干的代码才会发布到Production。

所以基本上任何进入trunk的代码都是来自分支的合并;这样，trunk只包含要发布的代码，您不必从修订版中进行笨拙的代码回滚或分支。

缺点是您需要不同的CI环境，每个分支都有不同的应用服务器域，以及主干和预生产。

Answer 3

确实有很多方法可以实现这一目标。应用修补程序的方法取决于修订控制和项目发布的整个过程。因此，我将通过描述我们为所有项目采用的基本revision control流程来为我的答案添加前缀：

1. /trunk包含主要开发分支，用于主动开发，除非进行大量工作，例如新的主要功能或重构。在这种情况下，开发人员将复制到/branches/foo，然后在工作完成后合并回/trunk。选择是否主要在/trunk工作或使用分支取决于开发人员的数量，项目的复杂性，项目的阶段和开发的速度。无论如何，最好尽量保持/trunk尽可能稳定。
2. 一旦达到里程碑，并且/trunk中的工作已准备好发布到生产站点，/trunk将复制到例如/tags/2.5.0（此版本的版本号） ）。
3. 此版本首先使用svn switch ^/tags/2.5.0应用于沙箱网站（例如 test.example.com ）（注意URL中的插入符号（^）表示法;）并显示给客户端或QA团队进行审核。
4. 如果客户或QA团队请求调整，则重复步骤1-3并增加次要版本号（例如，增加到/tags/2.5.1）。
5. 沙盒网站经过测试并获准发布后，用于启动沙盒网站的相同步骤将应用于生产网站（即svn switch ^/tags/2.5.1）。

那么，在我们需要将紧急修补程序应用于生产站点的情况下，我们将：

1. 使用/tags/2.5.1的本地工作副本或直接在沙盒网站上将修复程序直接应用于/tags/2.5.1的发布版本。
2. 如果更改是在本地工作副本中完成的，我们将提交更改并更新（svn up）沙箱站点。然后我们重复审核/批准过程。
3. 获得批准后，只需更新（svn up）生产网站。
4. 对/tags/2.5.1处的发布版本所做的更改将合并回/trunk。