svn - 使用 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 Training Options

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

几乎所有的开发都是在我们称为主干的一个位置完成的，但可以称为“开发”或“不稳定”或您想要的任何名称。

一些新功能的工作将在从主干创建的功能分支上完成。这些通常是短暂的，由开发人员自行决定。我们试图始终保持主干稳定(所有测试都通过)，因此有时人们想先在分支上尝试破坏性更改。

在某些时候，我们认为主干已经获得了我们想要的功能，是时候发布了，因此通过复制主干创建了一个发布分支。

我们不允许在发布分支中进行任何开发。错误在主干中得到修复，包含修复的修订被提名向后移植到一个或多个版本。如果获得批准，则修订版将合并到它们获得批准的发布分支。

有时，trunk 与发行版的差异很大，以至于修复程序不会干净地合并。当发生这种情况时，我们通过复制发布分支然后将修复从主干合并到后端口分支来创建一个后端口分支。这使开发人员能够适本地解决分支上的合并冲突，并且其他开发人员能够适本地审查和投票决定是否应该向后移植错误。

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

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