在这种情况下如何最好地使用 SVN？

Question

寻求关于我应该如何在我的产品开发中使用 SVN 的建议。

目前我正在使用我的产品的 2.2 版，并且已经开始使用 SVN 和 eclipse 来跟踪我的代码。不过，我将着手开发该产品的第 3 版，它与 2.2 版基本相同，但有一些大修和一些新功能。

问题在于，尽管 2.2 仍将进行错误修复和一些次要功能/调整，可能还会再发布 2-3 个版本，然后才成为固定版本，并且没有对其进行更多工作 - 希望及时发布版本 3。所以目前如果我的主干是 2.2 并且此时有一个稳定的标签，我从这里去哪里？请记住，我希望 3 是主干中此标记的分支，但由于 2.2 和 3 具有相似的类，如果我进行小的更改或错误修复，我希望它在版本 3 中体现，而不是必须实现在 v2.2(trunk) 和 v3 分支中修复了两次错误。

还值得注意的是，我的 v3 分支上可能有用于“实验性”功能的分支，这些功能可能不会进入该特定产品的第一个稳定版本。

对于这种情况的最佳实践的任何想法将不胜感激。

Answer 1

基本方法是为每个开发功能分支建立一个单独的 svn 分支。

其中一个实例是创建一个 2.x 分支，您可以在该分支上进行 2.2、2.3、2.4、... 系列的所有开发。这将基于您当前所在的位置，您可以使用标签来表示每个发布点。如果将来出现关键版本修复（例如，2.3.x），您还可以生成新分支以进行关键发布修复。然后你就可以在主干上继续你的主要开发了。

如果有必要，您当然会使用svn merge（如http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html 所述）来处理分支之间的合并。我强烈建议使用最新版本的 Subversion（例如 1.5），因为旧版本要求您手动跟踪已合并的更改，而新版本会为您处理跟踪该信息。

要处理您希望在分支之间向下或向上合并的简单错误修复，您可以使用 cherry-picking 在分支之间移动这些更改。

Answer 2

考虑这个存储库

根 |-- 后备箱 |-- 标签 | `-- 2.2 => 分支/version_2 的副本 `-- 分支 |-- version_2 => 2.2 的主干副本 |-- version_3_experimental => 2.2 的主干副本 `-- version_3 => 2.2 的主干副本

您在主干中为您的版本 3 进行所有开发，并且任何错误修复都在 version_2 分支中完成。如果为版本 2 开发的任何东西都应该在版本 3 中，则将其合并到主干中。之后，您将主干合并到分支/version_3 中。这样一来，您的后备箱就会根据版本 3 不断增长。

完成版本 2 后，从 version_2 分支创建标签。

希望这会有所帮助。

Answer 3

您可以使用svn merge 合并代码分支。

Answer 4

您的开发将如下所示：

                                              branch
                                              2.x -------------->
                                               |             |bring some more
                                               |  trunk 3.0  |changes if necessary
   trunk   --------------------------------------------------------------->
    2.2 stable        |      |      |        |  *     incorporated
       |              |      |      |        |  |Merge
   create branch     periodically bring      |  |branch 3 back
       |              | changes from trunk   |  |to trunk
       *              *      *      *        *  |
       branch------------------------------------X branch ends
         3                                            here

我的建议是在将 3.x 合并到主干之前延迟创建 2.x 分支。 这样可以减少合并的次数。

从那里开始的任何更改都可以带到trunk（3.x），但不能以其他方式。这是您逐步淘汰 2.x 以支持 3.x 时的典型方法。