如何为紧急修复设置SVN回购？

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

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

这通常工作得很好，但当代码未在主干中最终确定时，我们确实需要对生产进行紧急/紧急更改

我如何设置回购以适应这种情况？我认为这是一个很好的回答，但我还是有点不知所措

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

这是我想有一个更好的解决方案的情况，因为它已经发生了几次

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

更新：

在阅读了SVN书籍的分支部分之后，我正在考虑以下设置

准备推送到产品时创建分支

svn副本/主干/分支/生产\u 01-m“生产发布”

在生产中，切换到生产分支

svn交换机/分支机构/生产\u 01

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

svn结帐/分支机构/生产\u 01

//进行更改

svn merge/trunk#确保更改也被合并到trunk中

svn提交-m'紧急修复

生产时，更新到最新的分支

svn更新

---

这个过程听起来对我们的设置有效吗？

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

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

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

---

缺点是您需要不同的CI环境，每个分支具有不同的应用程序服务器域，加上主干和预生产。

在大型团队中，每次创建一个新分支以准备发布到生产环境是必要的，因为在您尝试稳定此版本的同时，人们仍然希望为将来的版本检查新功能。除非您一次支持多个生产版本，否则在一个小团队中这并不是真正必要的

在你的情况下，我将保留一个永久的

生产分支机构。无论何时进行正常发布，都要将其稳定在
trunk
，将
trunk
合并到
production
，然后从那里进行测试和推送

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


1始终从要合并回的最旧分支开始分支。它使合并更加干净。
确实有很多方法可以实现这一点。应用修补程序的方法取决于修订控制和项目发布的整个过程。因此，我将通过描述我们在所有项目中采用的基本流程来说明我的答案：

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