使用SVN进行多版本开发

Question

我的团队正在使用SVN来管理他们的源代码管理。我已经接受了任务，看看是否有改进我们使用SVN的方式。

我已经阅读了很多SVN书，并且对其他人如何使用SVN做了大量的研究。

我要去给我们如何使用svn进行概述，希望有人给我一些建议。

首先，我们每个月或两个月发布一次。因此，目前我们使用trunk作为代码的生产副本，并为每个计划交付和每个生产修复创建一个发布分支。

我们通常有两个，有时三个计划交付在同一时间。例如，我可能正在编写发行版本3，但我或其他人正在测试发行版本2并为发行版本1进行最终错误修复。可能还有一个生产修复程序正在同时进行。

现在我们做了大量的合并工作，以保持分支机构（每个版本）的同步。发行版3需要2和1的代码，但我们显然不希望发行版3的新代码进入发行版1.因此，我们将执行从发行版1到发行版2以及发行版2到发行版3的一系列合并。必须定期进行多次，以上发布3编码器具有从2或1

bug修复每当释放或产生修复投产，我们将这些代码合并到主干。然后我们将它从主干（或刚刚投入生产的发布分支）合并到所有活动分支中。

正如你可能已经注意到我们花了很多时间合并。

对于控制源代码控制的人来说，这是很多工作。他们不断地进行合并，并确保他们跟踪哪些分支合并在哪里。

好像SVN作为我们的源代码控制管理系统（我知道这是真的只有版本控制，但我们都用它来管理我们的源代码控制），应该能够帮助我们了这一点。

例如，如果开发人员在Release 3上工作时知道何时在版本2，发行版本1或主干上发生了某些变化，并且开发人员可以自动通知并且可以进行合并以将更改变为他的分支。但相反，有人必须知道手动进行所有合并......看起来像人正在做太多的工作，而且机器做得不够。

有没有人对我们如何能够更好地利用SVN的功能有所想法，这样我们就可以节省自己的一些头痛问题，并确保每个人都始终使用他们应该是的代码版本！

谢谢！

Answer 1

我不知道你可以通过论坛上的问题和答案逼真地解决这种情况。您最好的选择可能是从像我的雇主CollabNet这样的公司来看专业服务。 Subversion Training Options

让我们抛开像“主干”了一下名字，因为这些东西是说你希望他们意味着什么。我是Apache Subversion的提交者之一，我会推荐进行一些开发，就像我们为Subversion本身做的一样。

1. 几乎所有的开发都在我们称之为“trunk”的单一位置完成，但可以称为“开发”或“不稳定”或任何您想要的名称。
2. 有关新功能的一些工作将在从主干创建的功能分支上完成。这些通常是短暂的，并由开发人员决定。我们尽量保持我们的行李箱在任何时候都保持稳定（所有的测试都通过），所以有时候人们首先想要在分支上尝试破坏性的变化。
3. 在某些时候，我们认为trunk已经获得了我们想要的功能，以便发布一个版本，因此发布分支是通过复制trunk来创建的。
4. 我们不允许在发布分支中进行任何开发。错误在trunk中修复，并且包含修复的修订被提名为backport到一个或多个版本。如果获得批准，则修订版本将合并到批准的发布分支中。
5. 偶尔，主干已经发布足够的分歧，修复不会干净地合并。当发生这种情况时，我们通过复制发行版分支来创建一个后端分支，然后将修复从trunk中合并到backport分支中。这使得开发人员能够适当地解决分支和其他开发人员的合并冲突，以便正确审查并投票决定是否应该回报bug。

这种模式效果很好，因为变化总是只在一个方向合并，您不必担心有人作出快速修复一些版本，然后忘记使后备箱同样的修复。所以这个错误不会在下一个版本中显示出来。

我会指出Subversion的开发是相当线性的。如上所述，我们没有3次发布。我们仍然一次支持3个版本，但回溯的修复数量很少。我认为这个过程可以用于描述更加流畅的环境，但我认为在尝试解决问题时，让服务专业人员更紧密地合作会更好。