使用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 培训选项

让我们暂时将“trunk”之类的名称放在一边，因为这些东西的含义与您想要的含义无关。我是 Apache Subversion 的提交者之一，我建议像我们对 Subversion 本身所做的那样进行开发。

事实上，所有开发都是在一个我们称为主干的位置完成的，但也可以称为“开发”或“不稳定”或任何您想要的名称。
一些新功能的工作将在从主干创建的功能分支上完成。这些通常是短暂的，由开发商自行决定。我们尝试始终保持主干稳定（所有测试都通过），因此有时人们想首先在分支上尝试破坏性更改。
在某个时候，我们认为 trunk 已经获得了我们想要的功能，是时候发布版本了，因此通过复制 trunk 创建一个发布分支。
我们不允许在发布分支中进行任何开发。错误已在主干中修复，并且包含修复的修订版被指定向后移植到一个或多个版本。如果获得批准，则修订将合并到它们被批准的发布分支。
有时，主干与发布版本的差异很大，以至于修复程序无法完全合并。发生这种情况时，我们通过复制发布分支然后将修复从主干合并到向后移植分支来创建向后移植分支。这使得开发人员能够适当地解决分支上的合并冲突，并且其他开发人员能够正确地审查并投票决定是否应该向后移植该错误。

这种模型运作良好，因为更改总是只在一个方向合并，您不必担心有人对某个版本进行快速修复，然后忘记在主干中进行相同的修复。因此该错误不会在下一个版本中再次出现。

我要指出的是，Subversion 的开发是相当线性的。正如您在上面指出的那样，我们没有正在发布 3 个版本。我们仍然一次支持 3 个版本，但向后移植的修复数量很少。我认为这个过程可以适用于像您所描述的更加流动的环境，但我认为当您尝试解决问题时，最好有一个服务专业人员与您更密切地合作。