使用SVN进行多版本开发

Question

我的团队正在使用SVN来管理他们的源代码管理。我被赋予了一个任务，看看是否有改进我们使用SVN的方式。

我已阅读了很多SVN书籍，并对其他人如何使用SVN进行了大量研究。

我将概述我们如何使用svn，希望有人对我提出一些建议。

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

我们通常有两个，有时三个预定的交付同时进行。例如，我可能正在为第3版编写代码，但我或其他人正在测试第2版并对第1版进行最终的错误修复。可能还会同时进行生产修复。

现在我们进行了大量的合并以使分支（每个版本）保持同步。版本3需要来自2和1的代码，但我们显然不希望版本3中的新代码进入版本1.因此，我们将进行从版本1到版本2以及从版本2到版本3的一系列合并。必须定期重复第3版的编码器和2或1的错误修复。

每当发布或生产修复程序投入生产时，我们都会将代码合并回主干。然后我们将它从主干（或刚刚进入生产的发布分支）合并到所有活动分支中。

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

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

似乎SVN作为我们的源代码管理系统（我知道它实际上只是版本控制，但我们用它来管理我们的源代码控制）应该能够帮助我们解决这个问题。

例如，如果在版本3上工作的开发人员知道在版本2，版本1或主干上发生了哪些更改，并且开发人员可以自动得到通知并且他可以进行合并以将更改发送到他的科。但相反，有人必须知道手动完成所有合并......似乎人类做了太多的工作而且机器做得不够。

有没有人对我们如何能够更好地利用SVN的功能有任何想法，这样我们可以省去一些头痛的事情，并确保每个人都在使用他们应该的代码版本！

谢谢！

Answer 1

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

让我们暂时放下像“主干”这样的名字，因为这些东西意味着你想要的意思。我是Apache Subversion的提交者之一，我建议像Subversion本身一样进行开发。

1. 几乎所有开发都在一个我们称为trunk的位置完成，但可以称为“开发”或“不稳定”或任何你想要的名称。
2. 有关新功能的一些工作将在从trunk创建的功能分支上完成。这些通常是短暂的，并由开发人员自行决定。我们试图保持我们的主干始终保持稳定（所有测试都通过），所以有时人们希望首先在分支上尝试破坏性的更改。
3. 在某些时候，我们认为trunk已经获得了我们想要的功能，现在是时候发布了，所以通过复制trunk创建了一个发布分支。
4. 我们不允许在发布分支中进行任何开发。错误在trunk中修复，包含该修订的修订版被指定用于一个或多个版本的backport。如果获得批准，则修订将合并到他们批准的发布分支。
5. 偶尔，主干已经从发行版中分歧得足以解决修复程序无法完全合并的问题。当发生这种情况时，我们通过复制release分支然后将修复从trunk更新到backport-branch来创建一个backport-branch。这使开发人员能够适当地解决分支机构和其他开发人员的合并冲突，以正确审查并投票是否应该向后移植错误。

此模型运行良好，因为更改始终只在一个方向合并，您不必担心某人快速修复某些版本，然后忘记在主干中进行相同的修复。所以这个bug在下一个版本中没有显示出来。

我将指出Subversion开发是相当线性的。如上所示，我们没有3个正在发布的版本。我们仍然一次支持3个版本，但被反向移植的修复程序数量很少。我认为这个过程可能适用于你所描述的更加流畅的环境，但我认为你最好让一个服务专业人士更紧密地合作，因为你试图解决这个问题。