使用没有中继的Subversion

Question

我的团队最近决定不使用大多数颠覆存储库布局典型的"trunk"分支.我们发现,在任何特定时刻,总会有一个特定的分支在传统角色中起作用,而干线将在其他存储库中保存.也就是说,我们总是有一个编号最高的分支,代表我们正在开发的下一个版本.因此合并到主干简直是多余的,所以我们摆脱了主干.

有没有其他人这样做？

如果是这样,你有没有注意到任何利弊？

即使你的团队没有这样做,有没有人对这个布局有任何想法？

Answer 1

您正在谈论促销模型 - Perforce的论文强调了它的问题 - 沟通代码行的不断变化的角色和分支机构之间的工作.

我对所列问题的看法有所扩展:

1)改变代码行政策:

每个代码行都有一个策略,无论是写下来还是形式化,还是完全隐含在开发人员的头脑中.它定义了例如:

• 谁被允许提交代码行
• 需要多少测试(例如,单元测试必须通过,回归测试,完整的系统测试)
• 有多少人需要编写审核更改
• 允许什么样的变化

使用主干方法,策略保持固定,因此更容易记录,这使得它们更容易通信(在更大的团队中更重要).

例如Trunk:

• 任何开发者都可以提交
• 任何改变
• 单元测试必须通过
• 提交后的代码审查

版本分支:

• 只有维护开发者
• 只有bug修复
• 单元测试+回归测试
• 在提交之前由其他2位开发人员进

标签分支:

• 创建后没有提交

开发者的私人分支:

• 只有开发人员签到
• 任何改变
• 只有在合并到主干之前才需要进行测试
• 合并到主干之前的代码审查

如果您有促销模型,那么在主要开发阶段就有一个策略,然后必须在准备发布时更改策略时告诉所有人,然后在发布行时再告知其他策略(代码行).

促销模型很容易进入,它直接映射到非源控制的工作方式.但是一旦你开始获得大型团队,它就会受到伤害.

如果你看看Linux内核开发,你可以看到Promotional模型和Trunk模型之间的紧张关系:Linus的树是促销 - 它经历了合并窗口和rc /稳定期之间的循环.但Linux-next和-mm如雨后春笋般涌现,以提供更多的干线.

无论如何,分布式SCM/VCS有些不同,不必将策略分发给所有开发人员,因为每个开发人员都有自己的树,并在需要时进行更改.

开源项目遇到的问题是,他们不能强迫人们在从主干分支后进行稳定释放的苦差事.因此,促销模式作为强制稳定工作的一种方式更为重要,而不仅仅是处理功能.

2)搬家工作:

当他正在处理的行的策略仅改变错误修复时,开发人员可能正在处理某个功能,他现在需要将其工作副本切换到不同的代码行.根据使用的SCM系统,这可能是从易到难的任何地方.如果开发人员正在使用trunk,则不会发生此问题,因为他们的工作始终是中继.如果开发人员在私人或功能分支上,那么他们的工作将只会影响主干(和发布).

如果某个功能已经签入,但是从当前版本的版本中延迟,则必须确定如何删除它.这个问题仍然存在于主干模型中,但可能更容易解决 - 从发布版本的主干中挑选内容.这是功能分支帮助的地方 - 但它们具有集成成本.

Answer 2

Perforce论文的问题在于它拒绝了促销模式而没有提到主要优势,减少了合并开销.事实上,该论文错误地指出"主线模型"强加"没有额外的行政管理费用",这是一个荒谬的主张."始终合并到主干"模型意味着 - 你有每个人必须合并的开销.如果你有以下情况(我们有),这是毫无意义的开销:

a)一个小团队(5到7名开发人员)都在彼此的呼喊距离内.当我们需要建立一个分支时,沟通是一个非问题

和

b)一个代码库,其中实际上只有两个主要分支 - 一个生产分支和"开发中的下一个".也许曾经在蓝色的月亮中我们有3个.

我想我的观点是 - 这是一种情境化的东西.说"促销模式有问题"就像是说"从不使用OR/M".这取决于您的环境.