我想在我的项目中介绍以下分支模型
版本1 - ＆gt; version2 - ＆gt; version3 - ＆gt; version4 - ＆gt;等。
所以 1）没有行李箱 2）每个版本都是从前一个版本分支的
这里不会出现性能问题与不断增加的“分支深度”有关吗？
提前致谢
答案 0 :(得分：1)
没有。我们经常做这样的事情。当我们将一个版本部署到生产环境时，我们建立一个分支来保存状态，就像它进入生产一样。然后trunk成为我们的下一个常规版本。但是，如果经常发生错误或其他一些热修复，我们会在生产分支上创建一个新的分支。当下一个热修复程序出现时，我们从先前的热修复分支中分支出来。等等，比方说我们有分支/ Release-10。然后我们有一个热修复，所以我们将Release-10复制到Release-10-1。如果我们有另一个热修复，我们将Release-10-1复制到Release-10-2。等等。我没有看到这个方案有任何特殊问题。 （我们必须将热门修复程序合并到主干中，但我认为任何方案都不得不这样做。）
复制分支时，SVN并不真正复制所有内容。它只是复制指针。 SVN的一个主张是制作分支的成本非常低。
答案 1 :(得分：1)
基线方法优于推广模式
我会考虑“促销模式”，其中一个版本基于直接在其前身上作为反模式。但是，它不会产生重大的性能问题。只要你没有独特的并行开发，你就可以很好地适应它。甚至与“标准”基线模型一样。过去，它在一个非常线性的项目中对我有用。
虽然维护版本需要的时间越长，手中的版本就越多，但会越来越难。需要更多的策略来实现分支稳定性和期望的变化传播，从而导致管理开销的显着而不一定的线性增长。
您可能还有更多难以跟踪的合并。在您的方案中，将错误修正仅签入最新版本的纪律至关重要。
使用你所描述的分支布局，在一个大团队中，你永远不能完全确定你不会留下你将来需要的“后面”变化，因为你不断挑选，而你的分支永远不会“一起”。这就是为什么我喜欢称它为“错误促销模型”，而在基于主线的方法中，可能发生的最糟糕的事情是在未来的一个版本中缺少修复，而不是在所有版本中都缺少。
使用基线方法。它经过战斗验证，可以很好地代表您似乎想到的版本。 记住“复制，合并”，也许可以阅读“豆腐规模”：）
简而言之：
trunk
branches
1
2
3
tags
1.0
1.1
1.2
2.0
2.1
我推荐这个（旧）但非常有效的阅读：http://www.vance.com/steve/perforce/Branching_Strategies.html