SVN多个分支与“相关性”

我有一个SVN仓库与躯干，一些开发商继续添加代码（如它应该）

然后我们有不同的分支（见图片）p1_test（测试系统）和p1_live（生产系统）。

我们想要的过程是每隔X天从干线（进程v¹）更新p1_test分支。然后从p1_test的工作副本中的“真实文件”将被更新（v²）。

系统p1_test未通过测试，且每个错误修正已（或应该）提交给p1_test分支，且p1_test系统已更新（v²再次）。与此同时，其他不参与p1-cycle的开发人员将继续添加到主干中。这些更改应该而不是被集成到p1_test分支（尚）。

最后（当p1_test）被认为是稳定的时，应该从p1_test分支更新分支p1_live，并且对p1_test所做的所有更改应重新集成到主干（v³）。

在给定的时间点v 4被执行，意味着p1_live的工作副本从p1_live分支更新。

即使所有的东西都应该经过良好的测试，我们必须有选项来“修补”p1_live上严重错误的任何东西。在这种情况下，直接对p1_live分支进行更改，并从该分支更新系统（v 5）。

该过程必须与未知数量的pX_test和pX_live系统并行工作。

Svn Branching Schema

是这甚至可能使用SVN？目前我面临着不少版本号冲突等问题。

有没有版本控制系统可以让我按照给定的程序？

亲切的问候， Timetrick

来源

2012-09-19 Timetrick

我们使用Subversion与类似的使用方式，你一个大活跃的代码库。我们有标准的中继/分支/标签基础层次结构。在分支机构中，我们有unstable,testing和stable。我们也有分支文件夹中每个用户名的文件夹的“用户”分支。标签正是他们应该如何：一个不可触摸的快照。

trunk 

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

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

随着使用Subversion所有我的经验，我发现它的作品这么多更好，如果代码中一个方向流动。例外是从中继创建分支，当分支完成时（通常称为“重新集成”分支），当然可以合并更改回中继。
如果代码不能在一个方向上流动，那么它必须至少保留一条路径。例如，这意味着分支的一个分支不应该直接重新集成到中继线中。
我们的使用模式表明，所有活动的开发（包括bug修复，总是首先进入主干，然后主干为不稳定，测试和稳定分支的更新提供者）。（这也将是没关系遵循trunk -> unstable -> testing -> stable合并路径，但我们不由于具体到我们的测试/发布过程的原因。）
如果你有一个特定分支的修复程序，然后使它那里，不打算把合并回主干。我的经验发现，意外地有一个无辜的分支更新中断代码，或者甚至从干线，但没有提供给分支，但仍然是代码。

你可以从我的观点收集了Subversion需要一个过程，只要你想（和我们一样的）要真正有效地使用它，并避免那些奇怪的冲突中离开你说：“现在怎么办？”您所描述并试图弄清的所有内容听起来对我来说都非常熟悉Subversion。

我经常考虑如果像Git或Mercurial这样的DVCS工具没有这些问题（在所有?? ??）的宣传值得花费时间来迁移我们的知识库（数百个）。阻止我尝试的唯一因素是时间限制，但是您可以更好地尝试其中一种工具。

来源

2012-09-19 15:18:19 jimp

好吧，我改成了GIT。

感谢this wonderful blog post我把它启动并运行。（这是我所要求的，甚至更多...）

来源

2012-09-28 06:27:19 Timetrick

SVN多个分支与“相关性”

回答

相关问题