莫名其妙的 SVN 存储库大小从小差异增加到大文件答案

【问题标题】：Inexplicable SVN repository size increase from small differences to big files莫名其妙的 SVN 存储库大小从小差异增加到大文件
【发布时间】：2011-10-18 13:14:43
【问题描述】：

我不明白为什么大文件的微小差异会导致我的 subversion 存储库增长如此之多。

我有一些测试使用的数据库内容的 zip 文件。我想将每个新版本的测试数据存储在我们的 subversion 存储库中。

我做了一些实验，检查了 data.zip 的最后几个版本，并查看了存储库大小的变化。未压缩的数据约为 150MB，压缩和压缩后约为 50MB。签入存储库的每个新版本的 data.zip 文件都会使存储库的大小增加约 50MB。我认为它应该只增加一个我预计会少得多的增量。

Subversion 使用 xdelta 来存储压缩的差异数据。我确认 SVN 可以做得更好的尝试是下载 xdelta 并检查两个版本之间没有太大区别。确实

xdelta3.0z.x86-64.exe -e -s v1_path\data.zip v2_path\data.zip v1v2_delta.file

生成了一个大约 3MB 的 v1v2_delta.file。

我查看了位于 [myrepo]\db\revs 的 SVN 存储库，可以看到每个新修订的大文件

02/08/2011  11:12        57,853,082 4189
02/08/2011  11:40        51,713,289 4190
02/08/2011  11:46        52,286,060 4191

（4189、4190、4191是文件名）

我什至尝试在不压缩的情况下压缩 data.zip。这对 SVN 存储的内容没有影响——从外观上看，我的猜测是它存储了每个修订版的整个 data.zip 的压缩副本，而不仅仅是第一个修订版。我正在运行带有 FSFS 后端的 SVN 1.6。

关于提交二进制文件以及 SVN 如何存储增量，还有其他各种好的 stackoverflow 答案，例如SVN performance after many revisions。但是我无法从这些中看出为什么在上述情况下没有存储增量 - 即。如果 xdelta 可以让如此小的差异独立运行，那么 SVN 肯定也可以 - 或者它选择不这样做？！

编辑：我也尝试过 tar（未压缩）文件，SVN 再次无法有效地存储它们。此外，我发现我们在 SVN 刚刚存储差异的不同存储库中有一个相同数据格式的 zip 文件（尽管小得多）。

所以这个问题的总结版本是：SVN可以有效地存储二进制文件，例如10 slightly different CAD files are just 1.2 times the size of 1。 SVN 有时甚至可以通过压缩 zip 文件节省空间。但显然，二进制文件并不总是节省空间——在什么情况下会出现这种情况？

【问题讨论】：

关于“避免存储二进制文件”。在 Windows 上，这是不可避免的，尤其是在存储游戏编辑器工件的修订版或基于办公室的文档时。 “避免存储容易再生的二进制文件”更贴切。 svn 可以使用二进制增量的事实使它与其他所有免费可用的源代码控制系统不同，因为没有其他人可以做到这一点——它们都重新提交二进制文件，这导致了最终大小的巨大飞跃存储。

标签： svn delta

【解决方案1】：

总结

Subversion 有时会比 xdelta 独立版本更糟糕，因为压缩时需要占用多少内存。这是目前无法更改的颠覆行为，从 1.6 版开始。

详情

我在颠覆邮件列表why the subversion repository files seemed to be bigger than they should be上询问。

结论是xdelta can produce a smaller delta if you give it more memory。

在此线程中回读another example of someone else who had the same problem。

感谢最近和四年前 Subversion 邮件列表中的各种人。

也有这个问题？

如果您正在分析 subversion 存储库的磁盘使用情况，请了解 skip deltas 并使用此 grep DELTA trick 来确定用于 delta 的基础。

假设，像我一样，您确实想在存储库中存储二进制文件，这是我对一些解决方法的猜测（它们都不是很容易！）：

修改 subversion 源代码并构建您自己的源代码，并将 xdelta 内存窗口设置为更大
您是否拥有 xdelta-ing - 将 deltas 检查到源代码控制中，并进行一些疯狂的重建过程
迁移到 Git - 它一定会有更好的压缩（疯狂猜测）

【讨论】：

【解决方案2】：

我认为压缩将完全改变二进制文件的构成，因此 svn 将不得不存储巨大的增量。即使更改压缩文件内容的几个字符也可以彻底改变它。

在源代码管理中存储二进制文件通常是个坏主意，我认为您应该寻找替代方案。

【讨论】：

Re：压缩完全改变了二进制文件 - 这正是我的想法，因此尝试在不压缩的情况下进行压缩。但无论如何，我想不通的是，当从命令行独立运行时，xdelta 设法产生一个小的差异。鉴于 SVN 使用 xdelta，它肯定也应该实现一个小的差异吗？
如果您根本不压缩数据库并仅将其未压缩存储，您会看到什么结果？
在原始格式中，数据库数据是文件夹文件的巨大树。我可以提交这个的第一个版本。但是要提交第二个版本，我不能轻易地创建一个工作副本 - 我不能只是将第二个版本放在第一个版本之上，因为这会弄乱所有 .svn 文件夹。除非有人知道什么技巧？...
在我看来，将二进制文件存储在版本控制中是一个坏主意是不好的建议。应该将任何需要版本化的东西放入版本控制中。不对二进制文件进行版本控制或在其他地方对其进行版本控制可能同样糟糕。总的来说，我认为在所有“来源”之间建立紧密的联系，无论是文本还是其他方式，都比将事情分散开来更有帮助。仅当您有严重的扩展问题时才考虑替代方案，而且您可能没有。否则，应该归咎于您的版本控制，而不是您的做法。

【解决方案3】：

在压缩存档中添加或修改文件时，压缩文件的二进制内容可能会发生巨大变化。认为可能会发生更改可能会发生在存档的特定元素中，并且压缩文件文件的大部分区域不会发生重大更改。但是，在正常情况下会出现这种情况是“运气”的问题（当然这没有真正的运气，但计划实现它有点复杂）

这在熵编码算法中是很正常的，例如 Huffman（仅举一个最简单的算法），因为在添加或修改文件时符号的频率会发生变化。如果这发生在存档内容的开头，则可能会严重影响更改后文件的整个内容。

【讨论】：

【解决方案4】：

您是否使用了 fsfs 文件系统支持？我记得，它每次都存储一个新副本（尽管它可能被压缩）。您为什么希望 SVN 存储二进制文件的差异？ SVN 是一个源代码控制系统（意思是文本）而不是一个通用的二进制控制系统（尽管它在存储二进制文件方面做得不如它所能做的那么糟糕）。

【讨论】：

自 Subversion 1.4 subversion.apache.org/docs/release-notes/1.4.html "Subversion 使用 xdelta 算法来计算字节字符串之间的差异"，即。二进制文件。
Subversion 对所有内容都使用增量。它不知道也不关心文件是源文件还是二进制文件。它只是对以前的 repo 修订版做了一个增量（假设 FSFS）。