使用 SVN 进行多版本开发

Question

我的团队正在使用 SVN 来管理他们的源代码控制。我的任务是看看是否有办法改进我们使用 SVN 的方式。

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

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

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

我们通常会同时进行两个、有时三个预定的交付。例如，我可能正在为版本 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 本身所做的那样进行开发。

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

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

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