SVN：维护一个主干和一个错误修复分支
我将描述我想要实现的场景。我感兴趣的是使用 Subversion 是否可以实现这一点：
- 我正在开发一个向公众发布的应用程序。
- 它是使用 Jenkins CI 服务器构建的，并自动上传到 Web 服务器以供下载。
- 我将主要的开发工作放在主干上。主要版本来自主干，但发布频率并不高（每月 2-3 个）。
- 发布后，我希望能够快速修复任何错误，因此我有一个从最新主要版本分支出来的错误修复分支。在这里，可以相当快地（一天之内）解决并发布热修复程序。
- 在每个主要版本之后，我希望该错误修复分支以某种方式重新基于主干。换句话说，出于实用原因，我不想不断创建新的发布分支：CI 服务器保留相同的 SVN URL，不需要大量签出等。
问题：
- 是否可以在没有每次发布后需要从主干合并到错误修复分支吗？我担心各种树冲突，因为我对代码进行了大量重构。
- 做起来简单吗？
- 有其他策略吗？我知道我可以切换逻辑并将主要开发工作保留在分支上，但我想避免这种情况，因为大多数代码更改发生在主干上，这需要较少的合并工作。
- 对于这种情况，Mercurial 是更好的选择吗？
I'll describe the scenario I'm trying to achieve. I'm interested in whether this is possible using Subversion:
- I'm working on an application which is released to the public.
- It is being built using a Jenkins CI server and automatically uploaded to the Web server for download.
- I keep the major development work on the trunk. Major releases come from the trunk, but they are not very often (2-3 per month).
- After a release, I want to be able to quickly fix any bugs, so I have a bugfixing branch which is branched from the latest major release. Here the hot fixes can be solved and released fairly quickly (within a day).
- After each major release, I want that bugfixing branch to somehow be rebased to the trunk. In other words, I don't want to constantly create new release branches, for practicality reasons: CI server keeps the same SVN URL, no need for large checkouts etc.
Questions:
- Is the rebasing possible without the need to merge from the trunk to the bugfix branch after each release? I'm worried about various tree conflicts since I do a lot of refactoring of the code.
- Is it simple to do?
- Are there any alternative strategies? I know I can switch the logic and keep the main development work on a branch, but I want to avoid this because most of the code changes happen on trunk and this requires less merging effort.
- Is Mercurial a better option for such a scenario?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你所做的是一个有效的方法，你的问题是将更改合并回主干..然后合并它们。
首先，当您发布时，在此时创建一个分支 - 这是发布版本的代码。如果您愿意，您可以直接对其进行错误修复，这听起来像是您最好的工作方式。当您在那里进行错误修复时，只需将更改直接合并到主干即可。您不需要重新设置（或重新集成）或任何其他内容，只需将更改的修订版本合并到主干上即可。这非常简单 - 您正在执行 SVN 提供的最简单的合并（合并一系列修订），只需选择包含您想要的更改的修订并将它们合并到主干上。
在这种情况下您可能会遇到冲突，但请记住 svn 通过比较源更改并将其应用到目标来执行合并。如果将一个文件中的一半代码移到另一个文件中，然后尝试使用任何工具进行合并，则会遇到困难。
Mercurial 在这方面可能会更好 - 我建议尝试它，创建一个存储库，添加一些文件，分支，认真重构你的文件，然后进行一个小的更改并将其合并回来。看看您最终是否会遇到与 SVN 类似的问题（因为您正在尝试做大量工作，而且我认为任何计算机都不会擅长如此广泛的更改）。
当然，更好的答案是停止进行如此多的重构，让您的代码看起来像一个不同的产品！
what you do is a valid approach, you're problem is merging changes back onto trunk.. then just merge them.
Firstly, when you release, create a branch at that point - this is your code for the released version. You can bugfix directly onto it if you like, which sounds like the way you'd be best off working. When you make a bugfix there, just merge the change directly to the trunk. You don't need to rebase (or reintegrate) or anything, just take the revisions that changed and merge them onto trunk almost as they are made. This is very simple - you're doing the simplest merge SVN provides (merging a range of revisions), just pick the revisions that contain changes you want and merge them onto trunk.
You may run into conflicts in this case, but remember that svn performs merging by diffing the source changes and applying them to the target. If you move half the code out of a file into another and then try to merge using any tool, you'll have difficulties.
Mercurial might be better at this - I'd recommend trying it, create a repo, add some files, branch, seriously refactor your files, then make a small change and merge it back. see if you end up with similar problems that you'd get with SVN (as you're trying to do a lot of work, and I don't think any computer will be too good at such extensive changes).
Of course the better answer is to stop doing so much refactoring your code looks like a different product!
我在这个答案中至少找到了部分答案： 你应该如何处理旧的 SVN 分支？
所以基本上，我可以在每次发布后删除错误修复分支，然后创建一个具有相同内容的新分支 姓名。我不知道这是否是一个好的做法。
I found at least part of the answer in this SO answer: What are you supposed to do with old SVN branches?
So basically, I could delete the bugfixing branch after each release and then create a new one with the same name. Whether this is a good practice, I don't know.