如何设置 SVN 存储库以进行紧急修复？
作为一名多年的开发人员，这是我应该知道但却不知道的事情。
我正在一个小团队中开发已发布的产品。我是提交大部分代码的主要开发人员，但也有一些其他开发人员不时地提交。目前，我们有一个运行 Hudson CI 的临时服务器，它在每次提交后都会构建。当主干稳定并经过测试时，通过简单的 svn up 命令手动更新生产。
这通常工作得很好，除非我们确实遇到了当代码未在主干中最终确定时需要对生产进行紧急/紧急更改的情况。
我如何设置存储库来适应这种情况？我认为这个回应 是一个很好的回复，但它仍然有点超出我的理解。
我在想，在更新生产时，在该修订版中创建一个分支。但是，如果我需要进行紧急生产修复，如何访问该分支以及如何通过从该分支而不是主干拉取来更新生产？如何确保生产分支的任何紧急修复也提交到主干？
IE。这就是我想要更好的解决方案的情况，因为这种情况已经发生过几次
- Rev 1000 在生产中更新
- Rev 1001-1005 是新功能请求/错误修复，将包含在下一版本中
- Rev 1006 是紧急修复需要推送到生产版本
- Rev 1007-1009 是更多功能更新
- Rev 1010 应该是更新到生产版本的下一个版本
更新：
在阅读完 SVN 书籍的分支部分后，我正在考虑以下设置。
准备好推送到产品时创建分支
svn copy /trunk /branches/production_01 -m 'Production release'在生产中，切换到生产分支
svn switch /branches/development_01如果紧急修复如果需要，开发者需要在分支中进行更改：
svn checkout /branches/product_01// 进行更改svn merge /trunk # 确保更改也合并到主干中svn commit -m '紧急修复在生产中，更新到最新分支
svn update
这个过程听起来适合我们的设置吗？
Being a developer for a number of years this is something I should know but don't.
I am working on a released product on a small team. I am the main developer committing most of the code but there are a couple other developers that commit from time to time. Currently, we have a staging server running Hudson CI that builds after every commit. Production is updated manually by a simple svn up command when the trunk is stable and tested.
This has generally worked fine except we do have situations requiring emergency/urgent changes to production when code is not finalized in the trunk.
How can I setup the repo to accommodate this situation? I thought this response was a good reply but it is still a little over my head.
I am thinking, when updating production, create a branch at that revision. However, if I need to make urgent production fixes, how do I access that branch and how can I update production by pulling from that branch and not trunk? How do I make sure that any urgent fixes for the production branch are also committed to the trunk?
ie. this is the situation I want to have a better solution for because it has occurred a few times
- Rev 1000 is updated on production
- Rev 1001-1005 are new feature requests/bug fixes that will be included in the next version
- Rev 1006 is an urgent fix that needs to be pushed to production
- Rev 1007-1009 are more feature updates
- Rev 1010 should be the next revision updated to production
Update:
After reading through the branching section of the SVN Book, I am thinking about the following setup.
Create branch when ready to push to prod
svn copy /trunk /branches/production_01 -m 'Production release'On production, do a switch to the production branch
svn switch /branches/production_01If an urgent fix is needed, developer needs to make changes in branch:
svn checkout /branches/production_01// make changessvn merge /trunk # make sure changes get merged into trunk as wellsvn commit -m 'Urgent fixOn production, update to the latest branch
svn update
Does this process sound like it would work for our setup?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在大型团队中，每次创建一个新分支以便准备发布到生产环境是必要的，在大型团队中，人们仍然希望在您尝试稳定此版本的同时签入未来版本的新功能。除非您一次支持多个生产版本，否则对于小团队来说这并不是真正必要的。
在你的情况下，我会保留一个永久的
生产分支。每当您进行正常发布时，请将其稳定在trunk中，将trunk合并到生产中，然后从那里进行测试和推送。对于修补程序，请从
生产1 创建一个新分支，在其中进行更改，然后将其合并到生产和主干。与正常发布一样，您可以从生产进行测试和推送。1 始终从您想要合并回的最旧分支开始分支。它使合并更加清晰。
Creating a new branch every time in order to get ready to release to production is necessary in large teams where people still want to check in new features for future releases while you are trying to stabilize for this release. Unless you are supporting more than one production release at a time, that's not really necessary on a small team.
In your situation I would keep one permanent
productionbranch. Whenever you do a normal release, get it stabilized intrunk, mergetrunkintoproduction, and test and push from there.For a hotfix, create a new branch from
production1, make your changes in there, then merge it both intoproductionandtrunk. As with your normal release, you test and push fromproduction.1 Always branch from the oldest branch you intend to merge back into. It makes the merge much cleaner.
解决这个问题有不同的方法，但我认为我见过的最有效的方法如下：
所以基本上任何进入主干的代码都是来自分支的合并；这样，主干仅包含要发布的代码，并且您不必进行尴尬的代码回滚或从修订版分支。
缺点是您需要不同的 CI 环境，每个分支具有不同的应用程序服务器域，以及主干和预生产环境。
There are different ways of tackling this problem, but I think the most efficient way I have seen this done is the following:
So basically any code that goes into trunk is a merge from a branch; that way, trunk only contains code that is to be released, and you don't have to make awkward code rollback or branching from a revision.
The drawback is that you need different CI environments, with different app server domains for each branch, plus trunk and pre-prod.
事实上，有很多方法可以实现这一目标。应用修补程序的方法取决于版本控制和项目发布的整个流程。因此，我将通过描述我们为所有项目采用的基本修订控制流程来作为我的答案的前缀。项目：
/trunk包含主要开发分支，用于主动开发，除非进行大量工作（例如新的主要功能或重构）。在这种情况下，开发人员将复制到/branches/foo，然后在工作完成后合并回/trunk。选择主要在/trunk中工作还是使用分支，取决于开发人员的数量、项目的复杂程度、项目的阶段和开发的速度。无论如何，最好尽量保持/trunk稳定。/trunk中的工作已准备好发布到生产站点，/trunk就会被复制到，例如/tags/2.5 .0（此版本的版本号）。svn switch ^/tags/2.5.0应用于沙盒站点（例如，test.example.com）（注意插入符号 (^) 符号） URL ;) 并显示给客户或 QA 团队进行审查。/tags/2.5.1）。svn switch ^/tags/2.5.1）。因此，如果我们需要对生产站点应用紧急修补程序，我们将：
/tags/2.5.1的本地工作副本将修补程序直接应用于/tags/2.5.1的发布版本code>/tags/2.5.1 或直接在沙箱站点上。svn up) 沙箱站点。然后我们重复审查/批准过程。svn up) 生产站点即可。/tags/2.5.1发布版本所做的更改将合并回/trunk中。Indeed there are plenty of ways to achieve this. The method of applying hotfixes depends on the overall process of revision control and project releases. As such, I'll prefix my answer by describing the basic revision control process we employ for all our projects:
/trunkcontains the main development branch, used for active development except when extensive work takes place such as new major features or refactoring. In this case the developer will make a copy to/branches/foo, then merge back into/trunkwhen the work is done. Choosing whether to work mainly in/trunkor use branches depends on the number of developers, the complexity of the project, the stage of the project and the speed of development. In any case, it's best to try to keep/trunkas stable as possible./trunkis ready for release to the production site,/trunkis copied to, e.g.,/tags/2.5.0(the version number for this release).svn switch ^/tags/2.5.0(note caret (^) notation in URL ;) and shown to the client or QA team for review./tags/2.5.1).svn switch ^/tags/2.5.1).So then, in the case we need to apply an urgent hotfix to the production site, we will:
/tags/2.5.1using a local working copy of/tags/2.5.1or directly on the sandbox site.svn up) the sandbox site. Then we repeat the review/approval process.svn up) the production site./tags/2.5.1are merged back into/trunk.