我的团队正在使用SVN来管理他们的源代码控制。我的任务是看看是否有办法改进我们使用SVN的方式。
我读了很多关于SVN的书，并且做了很多关于其他人如何使用SVN的研究。
我将概述一下我们如何使用svn，希望有人能给我一些建议。
首先，我们每一两个月发布一次。因此，目前我们使用主干作为代码的生产副本，并为每个计划交付和每个生产修复创建一个发布分支。
我们通常有两个，有时是三个预定的交货同时进行。例如，我可能正在为版本3编写代码，但我或其他人正在为版本2进行测试，并为版本1进行最终的错误修复。同时也可能有一个生产修复正在进行。现在我们做了很多合并来保持分支(每个版本)同步。版本3需要版本2和版本1中的代码，但我们显然不希望版本3中的新代码进入版本1。所以我们会做一系列的合并，从版本1到版本2，从版本2到版本3。这将需要定期重复，以确保第3版的编码员拥有和第2版或第1版的bug修复。
每当一个发布版或生产版修复进入生产版时，我们都会将代码合并回主干。然后我们将它从主干(或者刚刚进入生产的发布分支)合并到所有的活动分支中。
你可能已经注意到我们花了很多时间合并。
对于控制源代码管理的人来说，这是一项大量的工作。它们不断地进行合并，并确保跟踪哪些分支在哪里合并。
似乎SVN作为我们的源代码控制管理系统(我知道它实际上只是版本控制，但我们正在使用它来管理我们的源代码控制)应该能够帮助我们解决这个问题。
例如，如果在版本3上工作的开发人员知道什么时候在版本2、版本1或主干上发生了变化，并且该开发人员可以自动得到通知，并且他可以进行合并以将更改合并到他的分支中，这将是非常棒的。但相反，必须有人知道手动完成所有合并……似乎人类做了太多的工作，而机器做得不够。
有没有人有任何想法，我们可以更好地利用SVN的特性，这样我们就可以省去一些令人头疼的事情，并确保每个人都在使用他们应该使用的代码版本!
谢谢!
我不知道你可以通过论坛上的问答来实际解决这样的情况。你最好的选择可能是看看像我的雇主CollabNet这样的公司的专业服务。Subversion培训选项
让我们暂时把像"trunk"这样的名字放在一边，因为这些东西意味着你想要的任何意思。我是Apache Subversion的提交者之一，我建议像我们对Subversion本身所做的那样进行开发。
- 几乎所有的开发都是在一个我们称为主干的地方完成的，但可以称为"开发"或"不稳定"或任何你想要的名字。 一些新特性的工作将在从主干创建的特性分支上完成。这些通常是短暂的，由开发者自行决定。我们试图在任何时候保持主干的稳定(所有的测试都通过了)，所以有时人们想先在分支上尝试破坏性的改变。
- 在某些时候，我们认为trunk已经获得了我们想要的特性，到了发布版本的时候了，所以通过复制trunk创建一个发布分支。
- 我们不允许在发布分支中进行任何开发。错误在主干中修复，包含修复的修订被指定为后移植到一个或多个版本。如果获得批准，则将修订合并到它们被批准的发布分支。
- 偶尔，主干与发布版本有足够的分歧，以至于修复不能干净地合并。当这种情况发生时，我们通过复制发布分支来创建一个后端分支，然后将修复从主干合并到后端分支。这使得开发人员能够适当地解决分支上的合并冲突，其他开发人员可以适当地审查并投票决定是否应该向后移植错误。
这个模型工作得很好，因为更改总是只在一个方向上合并，你不必担心有人为某个版本做了快速修复，然后忘记在主干中做同样的修复。因此，该错误不会在下一个版本中出现。
我将指出Subversion开发是相当线性的。正如你上面所说的，我们没有在飞行中有3次释放。我们仍然支持一次发布3个版本，但是反向移植的修复数量很少。我认为这个过程可以在你所描述的更灵活的环境中工作，但我认为你最好有一个服务专业人士与你更密切地合作，因为你试图解决这个问题。