具有“依赖关系”的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 -> unstable -> testing -> stable合并路径，但我们没有 由于我们的测试/发布过程特定的原因。）
• 如果您有针对特定分支的修复程序，请在此处进行修复，而不是计划进行修复 将它合并回主干。我的经验发现这是一个很好的方法 不小心有一个无辜的分支更新中断代码甚至删除代码 尚未提供给分支的干线。

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

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

Answer 2

好吧，我换成了GIT。

感谢this wonderful blog post我得到了它并且正在运行。 （这就是我要求它做的所有事情，甚至更多......）