版本控制 | 如何有效管理SVN服务器上的多个储存库

来源：Perforce 作者：龙智发布时间：2022-09-09

Subversion是一种集中式的版本控制系统，一般被简称为SVN。作为目前可用的众多版本控制选项之一，SVN依旧存在着分支功能弱、集中式导致服务器压力大等问题。

如果您的需求已经超过SVN所提供的功能范围应该怎么办？龙智将在系列文章中为您提供其他版本控制软件的实践参考。我们将从为什么使用SVN、SVN命令、托管储存库、如何使用客户端等角度对比Perforce Helix Core、SVN与Git，让您能够深入了解各个版本控制软件的优缺点。（请前往文末【往期推荐】中阅读已发布文章。）

作为DevSecOps研发安全运营一体化解决方案供应商，龙智持续关注版本控制领域动态与发展，为您提高最新洞察与最佳实践参考，帮助大型开发团队更好地进行数字资产管理与协作，提升研发效率。

SVN储存库是文件和目录的集合，不仅如此，它还记录着变更的完整历史记录。

现在的项目越来越复杂，一个项目通常有2个以上的SVN储存库。如何有效地对其进行管理呢？

一个SVN服务器上的多个SVN储存库

使用多个SVN储存库是组织和多样化数字资产的一种简单方法。例如，您可能同时拥有前端储存库和后端储存库。或者，您在一个储存库中有源代码，在另一个储存库中有二进制依赖项。

SVN服务器上可以设置多个储存库：

安装SVN服务器。
设置项目。
创建储存库。
使用根目录创建其他储存库。

您是否应该使用多个储存库？

多个SVN储存库的一个典型用例是基于组件的开发。当数字内容需要不断复用和共享时，SVN开发人员通常会创建多个储存库。这种策略有助于区分数字资产之间的依赖关系，但很难有效地管理储存库之间的开发。

现实是，在SVN中分支和合并多个代码线并不是一个简单的事情。而且，在混合中添加多个储存库会更加复杂。当需要发布时，很难确保分支和储存库之间的更改被正确地集成到构建中。

多个SVN储存库面临的三个挑战

分支与合并

小型分支是公认的最佳实践。但在大型项目中，长期分支仍然是有用的，尤其是在开发未来版本时。这就需要将代码从一个储存库中的分支移动到另一个储存库中。但是SVN的分支功能无法很好的应对这个挑战。

在SVN中，通过命名惯例来标识分支，分支和主代码线之间没有关系。这就很难识别需要在不同储存库的分支中传导的更改。

发布管理

当您使用两个或更多储存库时，质量控制和版本管理就会很困难。

假设您有一个专门用于开发的储存库，另一个包含主代码。要验证开发分支的修改是否进入了发布分支，是一个很麻烦的过程。

如果没有适当的控制和可追溯性，错误的构建和意外的代码冻结就会时常发生。

繁琐的变通方法

有一些解决方法可以简化多个SVN储存库的开发。您可以使用打补丁的方式，将更改从长期存在的分支复制到主干。但是，这需要涉及到一些深奥难懂的命令，也需要更多的监管。

开发团队也可以使用第三方多个储存库管理工具，如mr（mr是multiple repo的缩写，代表多个版本库）。使用mr命令，SVN开发人员就可以在一组储存库上执行签出、更新和其他操作，就像它们是一个综合储存库一样。但是，从在线社区来看，目前还不清楚这个工具是否被广泛使用，以及是否带来了真正的价值，或是否在其他方面让事情变得更加复杂。

虽然，一些解决方法可以减轻管理多个资源库的负担，但它们会造成复杂性和管理上的开销。