这是我想知道的。
我们将开发一个软件并发布它的主要版本v1.0。
如果我们发现任何错误，我们将修复这些版本并将修补程序版本p1.0.1应用于现有的主要版本v1.0，该版本仅包含用于修复错误的修改类。并且只要发现任何错误或必须应用增强功能，它就会继续发布，我们将发布一个新的补丁版本，以应用于现有主要版本和现有补丁。
那么，我们如何才能维护特定补丁版本的修改后的源（java）文件？就像我们需要有完整的源代码一样，我们必须在此基础上维护补丁源。我们必须在SVN中同步此代码，因为多人参与了错误修复和修补。
Trunk，Branches，Tags会满足我们的需求吗？
请建议。
答案 0 :(得分：1)
有几种标准的开发方式。我喜欢所谓的 unstable trunk 方法。
在不稳定的行李箱中，您可以在行李箱上进行所有开发。每个人都在一起工作。我们有超过100名开发人员，并没有遇到任何问题。它迫使开发人员一起工作，进行小的更改，并不断提交这些更改。
它也适用于像Jenkins这样的持续集成构建器。
当您进入魔术点时，您将创建发布分支。这个魔术点是什么？这取决于。我们的想法是，当您接近发布时，您将有一些开发人员正在开发即将发布的版本，而一些开发人员正在开发将在下一个版本中使用的功能。两组并行工作意味着分支。
在某些群组中，这是当您发布候选版本或者在发布时功能完成时，现在您只是修复错误。此时，您将为您的版本创建一个分支。我们的标准是在您发布后调用该分支。
你有一个由10名开发人员组成的团队。您正在使用1.2版。所有工作目前都在干线上。现在该版本已经基本完成，您可以指定其中两个开发人员使用QA和UAT来修复代码并处理发布。所有其他开发人员都在继续他们的工作。
您使用1.2创建一个名为svn cp的分支，以将trunk复制到branches/1.2。现在，那两个使用QA和UAT的开发人员在分支1.2上工作，其余的继续在trunk上工作。
准备好发布代码后，您可以使用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。
再次，您可以通过branches/1.2将svn merge -c $REV的各个更改合并到主干。
注意：无需创建1.2.1分支。但是，如果你愿意的话，没有什么能阻止你这样做。您可以将
tags/1.2复制到branches/1.2.1并在那里完成工作。然后，您可以在发布时将branches/1.2.1复制到tags/1.2.1。唯一可能的问题是，您的分支来自
trunk- ＆gt;branches/1.2- ＆gt;tags/1.2- ＆gt;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之间进行差异。