完全由同一作者复制：compress binaries in SVN?
您好，
我想构建一个脚本来包装提交和签出的问题。 我想在提交之前压缩二进制文件，并在结账后立即解压缩。
这样做的方法是什么？是IMPORT命令而不是COMMIT preferd，因为没有delta比较？我知道它不太节省空间，但仍然？
感谢， 奥德。
答案 0 :(得分：4)
Subversion的二进制增量算法之间的交互，跟踪文件中的压缩以及服务器自己内部使用的压缩都很复杂。
我把x86 emacs二进制文件的副本（大约10MB，用gzip压缩的4MB）作为我的“二进制文件”。我写了一个小程序，它通过用随机数据覆盖随机位置的4个连续字节来“编辑”二进制文件。
然后我编写了三个脚本来模拟以下三种方式的100次提交：
对于每次重复：我们解压缩文件，然后执行编辑，然后重新压缩，然后检入。
最终存储库大小：9.6 MB
（这比我预期的要好，直到我意识到由于gzip的工作方式，随机编辑之前的字节（文件的一半，平均而言）将与之前版本的字节相同，即使在压缩之后也是如此。）
每次重复：我们只需执行编辑，然后检查更改。
最终存储库大小：5.1 MB
对于每次重复：我们将二进制文件（不使用svn副本）复制到新文件，编辑此副本，添加它并提交更改。这相当于导入，因为与该文件的上一个副本没有历史连接。
最终存储库大小：403 MB
为了让您了解Subversion的服务器端压缩，我重复了这个测试，只是这次我在客户端压缩二进制文件，然后每次添加和提交它们。
最终存储库大小：392 MB
所以，无论颠覆是做什么的，它看起来和gzip一样好。
您的问题听起来好像是假设客户端的压缩会对您有所帮助。它可能不会这样做。
根据我的经验，它只值得做：
答案 1 :(得分：2)
压缩文件实际上会增加SVN存储库占用的空间。
为什么呢？ SVN服务器尝试仅存储二进制差异产生的增量。因此，通常只需要存储已更改的文件部分。
但是，如果压缩文件，那么最轻微的更改将完全改变压缩结果。 SVN服务器需要为每次提交存储完整的压缩文件，而不仅仅是更改的部分。