svn 存储库的实际大小限制是多少？答案

【问题标题】：whats the practical size limit of an svn repository?svn 存储库的实际大小限制是多少？
【发布时间】：2013-02-06 08:22:00
【问题描述】：

我正计划建立一个 svn 存储库，其中将包含我工作场所的各种产品构建所依赖的 3rd 方二进制文件。因为这些都是二进制文件而不是文本文件，所以任何添加到这个存储库都会复制工件，我有点担心大小限制。

现在我正在查看大约 15 GB 的二进制文件，我知道 350GB 是可能的（从这个问题可以看出 - 350GB SVN repo creates atleast 1MB revision for even a simplest task like branch/tag）。

我也知道底层操作系统施加了一些限制（例如，最大单个文件大小为 2GB，我不希望达到），并且 svn 代码中没有硬限制。

我要问的是，人们看到 svn 在没有重大问题的情况下获得了多大？还请记住，此存储库将（相对）很少更新 - 大约每几周更新一次。

我的操作系统选项是 windows x64（很可能是 server 2008）和 linux x64（可能是 red hat ent.）。文件系统将是 Windows 中的 ntfs 和我想要的 linux 上的任何文件系统。

客户端主要是 tortoise svn 1.7

那么在我的案例中，实际限制是什么？

【问题讨论】：

“因为这些都是二进制 blob” - 倒带。说什么？
我的意思是我将在那里存储大量非文本工件（*.dll、*.so、*.zip 等），所以我希望大小会快速增长
你为什么要在 svn 中存储二进制文件？除了 svn 之外，还有其他可能更合适的解决方案。
它实际上有点复杂。 “长期存储”（如备份和安全）将是 svn，但来自该 svn 的工件将部署到 nexus，而需要它们的构建将从那里获取它们。
Subversion 不是备份系统，所以请不要这样使用。将这些库保存在某种形式的另一个存储中（甚至是单独的 SVN 存储库，并通过外部引用），并将它们作为构建和分发过程的一部分拉入。

标签： svn

【解决方案1】：

首先，Subversion 是一个现代版本控制系统，因此二进制数据本身不是问题。 Subversion 可以从二进制数据创建增量，因此提交将尽可能小。

问题通常是二进制数据主动阻止生成小的增量。一个原因是二进制数据可以被压缩，这通常会导致巨大的差异。

也就是说，您的存储库可能无论如何都不会增长得非常快。我们有一个大产品，目前使用大约 400 个第三方依赖项。每个月，其中的一些变化。或者换一种说法：您的依赖项不会全部每周改变一次。这意味着您每个月只会添加几 MB（除非您有一个非常不稳定的依赖项，它会发生很多变化，但同样，大多数依赖项都不是那样的）。

所以我的直觉是尝试并解决出现的任何问题，因为无论如何可能不会有任何大/无法使用的问题。

【讨论】：