我不明白为什么大文件的微小差异会导致我的 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 如何存储增量,例如多次修订后的 SVN 性能,还有各种其他好的 stackoverflow 答案。但是我无法从这些中看出为什么在上述情况下没有存储增量 - 即。如果 xdelta 可以让如此小的差异独立运行,那么 SVN 肯定也可以 - 或者它选择不这样做?!
编辑:我也尝试过 tar (未压缩)文件,SVN 再次没有有效地存储它们。此外,我发现我们在 SVN刚刚存储 diffs的不同存储库中有一个相同数据格式的 zip 文件(尽管小得多)。
所以这个问题的总结版本是:SVN 可以有效地存储二进制文件,例如10 个略有不同的 CAD 文件的大小仅为 1 的 1.2 倍。SVN 有时甚至可以通过压缩 zip 文件节省空间。但显然二进制文件并不总是节省空间 - 在什么情况下会出现这种情况?