SVN：维护一个主干和一个错误修复分支

Question

我将描述我想要实现的场景。我对这是否可以使用 Subversion 感兴趣：

1. 我正在开发一个向公众发布的应用程序。
2. 它正在使用 Jenkins CI 服务器构建并自动上传到 Web 服务器以供下载。
3. 我将主要的开发工作保留在 trunk 上。主要版本来自主干，但并不经常（每月 2-3 个）。
4. 发布后，我希望能够快速修复任何错误，因此我有一个错误修复分支，它是从最新的主要版本分支出来的。在这里，热修复程序可以很快（一天内）得到解决和发布。
5. 在每个主要版本之后，我希望该错误修复分支以某种方式重新定位到主干。换句话说，我不想不断创建新的发布分支，出于实用性原因：CI 服务器保持相同的 SVN URL，不需要大量结帐等。

问题：

1. 是否可以在每次发布后无需从主干合并到错误修复分支的情况下进行变基？由于我对代码进行了大量重构，因此我担心各种树冲突。
2. 做起来简单吗？
3. 是否有任何替代策略？我知道我可以切换逻辑并将主要开发工作保留在分支上，但我想避免这种情况，因为大部分代码更改都发生在主干上，这需要较少的合并工作。
4. 对于这种情况，Mercurial 是更好的选择吗？

Answer 1

你所做的是一种有效的方法，你的问题是将更改合并回主干..然后合并它们。

首先，当您发布时，创建一个分支 - 这是您发布版本的代码。如果您愿意，您可以直接对其进行错误修复，这听起来像是您最好的工作方式。当您在那里进行错误修复时，只需将更改直接合并到主干。您不需要重新设置（或重新集成）或任何东西，只需将更改的修订版合并到主干上，就像它们一样。这很简单——你正在做 SVN 提供的最简单的合并（合并一系列修订），只需选择包含你想要的更改的修订并将它们合并到主干。

在这种情况下您可能会遇到冲突，但请记住 svn 通过区分源更改并将它们应用到目标来执行合并。如果您将一半代码从一个文件移到另一个文件中，然后尝试使用任何工具进行合并，您将遇到困难。

Mercurial 可能在这方面做得更好——我建议您尝试一下，创建一个 repo，添加一些文件，分支，认真重构您的文件，然后进行一些小的更改并将其合并回来。看看您最终是否会遇到与 SVN 类似的问题（因为您正在尝试做很多工作，而且我认为任何计算机都不会擅长如此广泛的更改）。

当然，更好的答案是停止对代码进行如此多的重构，看起来像是不同的产品！

Answer 2

我在这个 SO 答案中至少找到了部分答案：What are you supposed to do with old SVN branches?

所以基本上，我可以在每次发布后删除错误修复分支，然后创建一个具有相同名称的新分支。这是否是一个好习惯，我不知道。