如何在 Eclipse 的 svn 中使用树干、分支、标签？

Question

这是我想知道的。

我们将开发一个软件并发布它的主要版本 v1.0。

在将该版本投入生产后，如果我们发现任何错误，我们将修复这些错误并提供补丁版本 p1.0.1，以应用于现有的主要版本 v1.0，该版本仅包含用于错误修复的修改类。并且每当发现任何错误或必须应用增强功能时，我们都会发布一个新的补丁版本，以应用于现有的主要版本和现有的补丁。

那么，我们如何才能只维护特定补丁版本的修改后的源（java）文件？就像我们需要拥有完整的源代码一样，我们必须在此之上单独维护补丁源。我们必须在 SVN 中同步此代码，因为需要多人参与错误修复和修补。

Trunk, Branches, Tags 能满足我们的需求吗？

请提出建议。

Answer 1

有几种标准的开发方式。我喜欢所谓的unstable trunk方法。

在不稳定的主干中，您在主干上进行所有开发。每个人都一起工作。我们有 100 多名开发人员，并且没有任何问题。它迫使开发人员一起工作，进行小的更改，并不断提交这些更改。

它也适用于像 Jenkins 这样的持续集成构建器。

当你到达某个神奇的点时，你创建了一个发布分支。这个魔法点是什么？这取决于。这个想法是，当您接近发布时，您将有一些开发人员致力于即将发布的版本，而一些开发人员则致力于将进入下一个版本的功能。两个小组并行工作意味着分支。

在某些组中，这是当您到达候选版本的时候，或者当您在某个版本中完成功能时，现在您只是在修复错误。此时，您为您的版本创建一个分支。我们的标准是在您发布后调用该分支。

示例：创建版本

您有一个由 10 名开发人员组成的团队。您正在开发 1.2 版。目前所有工作都在主干上。现在发布几乎完成了，您分配其中两个开发人员与 QA 和 UAT 一起修复代码并处理发布。所有其他开发人员都在继续他们的工作。

您创建一个名为1.2 的分支，使用svn cp 将trunk 复制到branches/1.2。现在，这两个负责 QA 和 UAT 的开发人员在 Branch 1.2 上工作，其余的则继续在主干上工作。

准备好发布代码后，您可以使用svn cp 将branches/1.2 复制到tags/1.2。

您现在在 1.2 版本中修复了一些错误，这些错误可能适用于您在 trunk 中处理的 1.3 版本。在这种情况下，您可以使用svn merge -c $REV，其中$REV 是您修复相关错误的Subversion 版本。请注意，没有重新整合。您只需将branches/1.2 中的补丁应用到trunk。

示例：补丁发布

您已发布 1.2 版，但发现了一个严重错误。客户已经等不及 1.3 版了，所以您现在就修复错误并创建 1.2.1 版。

在这种情况下，由于您已经拥有branches/1.2，您只需修补该分支，然后当您准备好发布时，您将1.2 分支复制到tags/1.2.1。

再一次，您通过svn merge -c $REV 将来自branches/1.2 的各个更改合并到主干。

注意：无需创建 1.2.1 分支。但是，如果您愿意，没有什么可以阻止您这样做。您可以将tags/1.2 复制到branches/1.2.1 并在那里完成您的工作。然后，您可以在发布时将branches/1.2.1 复制到tags/1.2.1。

唯一可能的问题是您的分支来自trunk->branches/1.2->tags/1.2->branches/1.2.1。将/branches/1.2.1 合并回trunk 会导致旧版本的Subversion 出现问题。这在 Subversion 1.6 或更高版本中应该不是问题。

还有一条建议：不要重复使用版本名称或标签。您可以谈论发布 1.2，但每个补丁都应标记为 1.2.1、1.2.2、1.2.3 等。或者，1.2p1、1.2p2。关键是您应该能够指出您已交付到生产环境的每个版本。如果您想知道补丁 #3 中发生了什么变化，您可以在 1.2.2 和 1.2.3 之间进行比较。