我有一个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
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是更新提供者
对于不稳定,测试和稳定的分支. (也可以
按照主干 – >不稳定 – >测试 – >稳定的合并路径,但我们没有
由于我们的测试/发布过程特定的原因.)
>如果您有特定分支的修复程序,那么请在那里进行,而不是计划
将它合并回主干.我的经验发现这是一个很好的方法
不小心有一个无辜的分支更新中断代码甚至删除代码
尚未提供给分支机构的主干.
您可能会从我的观点中得出结论,Subversion需要一个过程才能真正有效地使用它(我们这样做),并避免那些让您说“现在是什么？”的奇怪冲突.对于Subversion来说,你所描述的所有内容以及试图找出的声音对我来说都太熟悉了.
我经常考虑围绕像Git或Mercurial这样的DVCS工具没有这些问题(根本没有？)的炒作是值得花时间迁移我们的存储库(数百个).阻止我尝试的唯一因素是时间限制,但你可能会更好地尝试其中一个工具.