用于压缩的SVN提交和签出的包装器[duplicate]

Subversion的二进制增量算法、跟踪文件中的压缩和服务器自身内部使用的压缩之间的交互可能很复杂。

这里有一个例子

我把一个x86Emacs二进制文件(大约10MB,4MB用gzip压缩)的副本作为我的“二进制文件”。我写了一个小程序,通过在随机位置用随机数据覆盖4个连续字节来“编辑”二进制文件。

然后,我编写了三个脚本,以以下三种方式模拟100次提交:

对于每个重复:我们解压缩文件,然后执行编辑,然后重新压缩,然后签入。

(这比我预期的要好,直到我意识到由于gzip的工作方式,随机编辑之前的字节(平均为文件的一半)将与上一版本相同,即使在压缩之后也是如此。)

该文件未在存储库中压缩

对于每个重复:我们只需执行编辑,然后签入更改。

最终存储库大小:5.1 MB

文件是 每次都是白手起家

对于每个重复:我们将二进制文件(不使用svn copy)复制到一个新文件中,编辑这个副本,添加它并提交更改。这相当于导入,因为与文件的上一个副本没有历史连接。

最终存储库大小:403MB

为了让您了解Subversion的服务器端压缩,我重复了这个测试,只是这次在每次添加和提交二进制文件之前,我压缩了客户端的二进制文件。

最终存储库大小:392 MB

你的问题让人觉得你 客户端的压缩将对您有所帮助。它很可能不会这样做。

1. 文件很大。
3. 该文件很少被编辑。

为什么?SVN服务器尝试只存储二进制扩散产生的增量。因此,通常只需要存储文件中已更改的部分。

但是,如果压缩文件,那么最轻微的更改将完全改变压缩结果。SVN服务器需要为每次提交存储完整的压缩文件,而不仅仅是更改的部分。