Subversion是一种集中式的版本控制系统，个别被简称为SVN。作为目前可用的泛滥版本控制选项之一，SVN仍旧存在着分支性能弱、集中式导致服务器压力大等问题。
如果您的需要曾经超过SVN所提供的性能范畴应该怎么办？龙智将在系列文章中为您提供其余版本控制软件的实际参考。咱们将从为什么应用SVN、命令备忘录清单、托管储存库、如何应用客户端等角度比照Perforce Helix Core、SVN与Git，让您可能深刻理解各个版本控制软件的优缺点。（已公布文章可在文末【往期举荐】中浏览。）
作为DevSecOps研发平安经营一体化解决方案供应商，龙智继续关注版本控制畛域动静与倒退，为您进步最新洞察与最佳实际参考，帮忙大型开发团队更好地进行数字资产治理与合作。
分支和合并是开发的次要内容。然而，SVN繁琐的分支和简单的合并模型始终备受用户诟病。本文将从SVN的分支与合并工作原理来剖析，并给出解决问题的方法。
首先，咱们将介绍Subversion的分支工作形式，以及如何应用SVN合并。
Subversion分支策略
Subversion分支（SVN分支）容许您的团队同时解决多个版本的代码，开发人员能够测试新性能，不会因谬误和bug影响其余开发工作。
SVN的“分支（branch）”目录与“骨干（trunk）”目录并行运行。SVN分支能够复制骨干，并容许您对其进行更改。当新性能稳固时，分支会从新合并。
以下是SVN分支和合并的根本分步概述：
- 应用svn copy命令创立分支。
- 应用svn checkout签出新的工作正本。
- 应用同步合并可使分支在工作时放弃最新。
- 应用svn merge将更改发送回骨干。
SVN分支和SVN合并的毛病
用户对SVN诟病最多的是其繁琐的分支和简单的合并模型。SVN分支作为储存库中的目录创立，这种目录构造是SVN分支的外围难点。它占用了开发人员大量的精力。
Subversion分支之间的关系
分支之间的关系以及分支与骨干的关系都不易存储在SVN中。开发人员必须提出命名计划或创立内部文档。
并行开发中的SVN合并
在您在解决分支时，偶然会从骨干合并到分支，以放弃目录最新。每次产生这种状况时，都会将更改复制到分支目录中。这可能会也可能不会反映其余开发人员正在进行的更改。
当分支准备就绪后，应用SVN合并提交回骨干。当然，您不是惟一一个进行合并更改的人。您的骨干版本可能不会反映开发人员的分支。这意味着抵触、失落的文件和凌乱的更改困扰着您的分支。
让咱们认真看一下这个例子：
1.0骨干有两个开发人员在不同的版本上工作。随着1.4和2.0开发分支的开发，它们将从骨干合并到开发分支以收集更新。
并行SVN开发对其余分支造成了无限的可见性。当1.4开发分支与骨干合并时，它被推送到开发中。这可能是把抵触降到最低的状况，但对于2.0开发分支就不一样了。
SVN树抵触
长期存在的分支呈现问题的危险会更大。SVN不会告诉您分支在骨干上的地位。您必须对代码进行梳理，找出它所在的地位以及短少哪些更改。
当更改目录构造时，通常会产生SVN树抵触，重命名或删除文件时可能会产生这种状况。因为这些更改很常见，您须要花点工夫来搜寻。
因为在产生树抵触时无奈提交更改，您必须手动解决每个谬误。即便应用“合并跟踪”，您也可能无奈找出分支中短少了哪些更改。这可能会重大提早部署。此外，随着团队规模的扩充，骨干可能会变得不够稳固，导致其更加难以保护。
如何解决SVN合并抵触和分支问题
很显著，SVN分支和合并是个问题。Perforce Helix Core提供了一种弱小而简略的分支办法：Perforce Stream。
开发人员能够应用工作流来解决我的项目的一小部分，而不会影响生产或其余开发人员。工作流定义了每个分支的目标：主线、开发、工作或公布。它们遵循主线模型，所有更改都流向主线，相似于SVN骨干。它让开发人员专一于本人的代码，而不是分支和合并。
分支层次结构的图形示意由工作流程图创立，这意味着您的团队始终晓得每个人在做什么。
此外，Streams的独占签出和颗粒度的权限设置让所有都清晰可见。这种流式传输策略解决了SVN分支的许多问题。在Perforce Helix Core中，没有固定的命名计划。Perforce Helix Core应用一个独自的数据库表来跟踪每次合并。还有许多办法能够跨分支跟踪更改：订正历史记录、延时视图和订正图。
文章起源：https://bit.ly/3AGWwtP