具有"依赖关系"的SVN多个分支

Question

我目前面临以下情况:

我有一个SVN存储库与主干,一些开发人员继续添加代码(因为它应该)

然后我们有不同的分支(见图)p1_test(测试系统)和p1_live(生产系统).

我们想要的程序是每隔X天从trunk(进程v¹)更新p1_test分支.然后将更新来自p1_test的工作副本中的"真实文件"(v²).

系统p1_test经过测试,每个错误修复都(或应该)提交给p1_test分支,并更新p1_test系统(再次为v²).与此同时,其他未参与p1-cycle的开发人员将继续加入trunk.这些更改不应该集成在p1_test分支中(尚未).

最后(当p1_test)被认为是稳定的时,应该从p1_test分支更新分支p1_live,并且对p1_test所做的所有更改都应该重新集成到trunk(v³).

在给定的时间点执行v⁴,意味着p1_live的工作副本从p1_live分支更新.

即使一切都应该被测试,我们必须选择"修补"p1_live上出现严重错误的任何内容.在这种情况下,直接对p1_live分支进行更改,并从该分支更新系统(v⁵).

此过程必须与未知数量的pX_test和pX_live系统同时工作.

这甚至可以用svn吗？目前我面临很多不同版本号,冲突等问题.

是否有版本控制系统可以让我遵循给定的程序？

亲切的问候,Timetrick

Answer 1

我们将Subversion用于具有与您类似的使用模式的大型活动代码库.我们有标准的trunk/branches/tags基础层次结构.在分支机构,我们有unstable,testing和stable.我们还有"用户"分支,在branches文件夹中每个用户名都有一个文件夹.标签正是他们应该如何:一个不可触摸的快照.

trunk

branches/unstable
branches/testing
branches/stable
branches/userA/branch1
branches/userA/branch2
...

tags/stable/rNNNN
tags/stable/vN.N.N.N
...

• 凭借我使用Subversion的所有经验,我发现如果代码仅在一个方向上流动,它的工作效果会更好.例外是从trunk创建一个分支,当然可以在分支完成后将更改合并回trunk中(通常称为"重新集成"分支).
• 如果代码不能在一个方向上流动,那么它必须至少保持在一条路径上.例如,这意味着分支的分支不应该直接重新集成回主干.
• 我们的使用模式是,所有活动开发(包括错误修复)总是首先进入trunk,然后trunk是不稳定,测试和稳定分支的更新提供者.(遵循trunk -> unstable -> testing -> stable合并路径也是可以的,但我们不会因为我们的测试/发布过程特有的原因.)
• 如果您有特定分支的修复程序,那么在那里进行修复并且不打算将其合并回主干.我的经验发现,这是一个很好的方式来意外地拥有一个无辜的分支更新中断代码,甚至从主干中删除代码,但尚未提供给分支机构.

你可能会从我的观点中得出结论,Subversion需要一个过程才能真正有效地使用它(我们这样做),并避免那些让你说"现在是什么？"的奇怪冲突.对于Subversion来说,你所描述的所有内容以及试图找出的声音对我来说都太熟悉了.

我经常考虑围绕像Git或Mercurial这样的DVCS工具没有这些问题(根本没有？)的炒作是值得花时间迁移我们的存储库(数百个).阻止我尝试的唯一因素是时间限制,但你可能会更好地尝试其中一个工具.