分支还是不分支，这是一个有趣的问题。本章深入探讨了分支和合并，这些主题历来是 Subversion 用户困惑的主要来源。就好像分支和分支管理中涉及的机械操作有时并不容易，一些用户会纠结于是否需要分支。正如您所了解的，Subversion 可以处理常见的分支和分支管理场景。因此，是否分支项目的历史记录很少是一个技术问题。相反，该决定的社会影响往往更重要。让我们来考察一下在软件项目中使用分支的一些好处和成本。

在分支上工作最明显的好处是隔离。对分支所做的更改不会影响项目中的其他开发线；对其他开发线所做的更改不会影响分支。这样，分支可以作为实验新功能、复杂错误修复、主要代码重写等的好地方。无论莎莉在她的分支上破坏了多少东西，哈利和团队中的其他人可以继续不受分支影响地进行他们的工作。

分支还提供了一种将相关更改组织成易于识别的集合的好方法。例如，构成特定错误的完整解决方案的更改可能是一系列非连续的修订号。您可以在人类语言中将它们描述为 “修订版 1534、1543、1587 和 1588”。您可能需要在跟踪错误的工单跟踪器工件中手动（或以其他方式）复制这些数字。在将错误修复移植到其他产品版本时，您需要确保移植所有这些修订版。但是，如果这些更改是在一个唯一的分支上进行的，您会发现自己只在对话中、在工单跟踪器评论中以及移植更改时引用该分支的名称。

然而，分支的不幸缺点是，使分支如此有用的隔离性可能与项目团队的协作需求相矛盾。根据项目成员的工作习惯，对分支进行的更改可能无法获得对主开发线进行的更改所进行的建设性审查、批评和测试。分支的隔离性可能会鼓励用户放弃某些版本控制“最佳实践”，导致版本历史难以事后审查。长期分支上的开发人员有时需要付出额外的努力来确保其代码库隔离副本的演变方向与同行引导主代码线的方向一致。现在，对于旨在探索代码库未来的真正探索性分支，这些缺点可能不太重要，这些分支没有将结果重新集成回主开发线的预期——仅仅是政策不应成为愿景杀手！但事实仍然是，项目通常受益于版本控制的有序方法，在这种方法中，代码和代码更改可以得到多个团队成员的审查和理解。

这并不是说分支没有技术上的处罚。请原谅我们在这里“进入元级”。如果你仔细想想，每次你检出 Subversion 工作副本时，你都会创建项目的一种分支。这是一种特殊的分支。它只存在于你的客户端机器上；不在存储库中。你使用svn update将此分支与存储库中进行的更改同步——这几乎就像svn merge命令的特殊情况下的简化形式。^[36] 每次运行svn commit时，你实际上都会重新集成你的分支。因此，从这个特殊意义上讲，Subversion 用户一直都在处理分支和合并。鉴于更新和合并之间的相似性，因此毫不奇怪，Subversion 似乎存在最大缺陷的领域——即处理文件和目录重命名以及处理一般树冲突——对于svn update和svn merge操作来说都是有问题的。不幸的是，svn merge更难处理，正是因为svn update是特殊情况下的简化通用合并操作，而真正的 Subversion 合并既不是特殊情况也不是简化。因此，合并的执行速度比更新慢得多，需要显式跟踪（通过我们在本章中讨论的svn:mergeinfo 属性）和历史压缩运算，并且通常会提供更多出错的机会。

是否要分支？最终，这取决于你的团队需要什么才能找到协作和隔离之间的最佳平衡。