包装到 SVN 提交并签出以进行压缩
可能的重复：
在 SVN 中压缩二进制文件？
同一作者的完全相同：在 SVN 中压缩二进制文件？
嗨，
我想构建一个脚本来解决提交和签出的问题。 我想在提交之前压缩二进制文件并在签出后立即解压缩。
有什么方法可以做到呢？ 由于没有增量比较，是否首选 IMPORT 命令而不是 COMMIT？ 我知道这不会节省空间，但仍然如此？
谢谢， 奥德.
Possible Duplicate:
compress binaries in SVN ?
exact duplicate by same author: compress binaries in SVN?
Hi,
I want to build a script to wrap the issues of commit and checkout.
I want to compress binary files before commiting and to uncompress right after checkout.
What is the way to do it? is the IMPORT command instead of COMMIT preferd because there is no delta comparrison? I know it wouldn't be space-efficient, but still?
thanks,
Oded.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Subversion 的二进制增量算法、跟踪文件中的压缩以及服务器自身内部压缩使用之间的交互可能很复杂。
下面是一个示例，
我将 x86 emacs 二进制文件的副本（大约 10MB，用 gzip 压缩为 4MB）作为我的“二进制文件”。 我编写了一个小程序，它通过用随机数据覆盖随机位置的 4 个连续字节来“编辑”二进制文件。
然后，我编写了三个脚本，以以下三种方式模拟 100 次提交：
文件在存储库中使用 gzip 进行压缩
对于每次重复：我们解压缩文件，然后执行编辑，然后重新压缩它，然后签入。
最终存储库大小：9.6 MB
（这比我预期的要好，直到我意识到由于 gzip 的工作方式，随机编辑之前的字节（平均为文件的一半）将与以前版本的字节相同，即使在压缩之后也是如此。）
文件在存储库中未压缩
对于每次重复：我们只需执行编辑，然后签入更改。
最终存储库大小：5.1 MB
每次都从头开始导入文件
对于每次重复：我们将二进制文件（不使用 svn 副本）复制到新文件，编辑此副本，添加它并提交更改。 这相当于导入，因为与文件的先前副本没有历史连接。
最终存储库大小：403 MB
为了让您感受 Subversion 的服务器端压缩，我重复了此测试，只是这次我在每次添加和提交二进制文件之前在客户端压缩它们。
最终存储库大小：392 MB
因此，无论 subversion 正在做什么，它看起来都与 gzip 一样好。
您的问题听起来好像您假设客户端的压缩会对您有所帮助。 它很可能不会这样做。
根据我的经验，只有在以下情况下才值得这样做：
The interaction between Subversion's binary delta algorithms, compression in tracked files and the server's own internal use of compression can be complex.
Here's an example
I took a copy of the an x86 emacs binary (about 10MB, 4MB compressed with gzip) as my "binary file". I wrote a little program which "edits" a binary file by overwriting 4 consecutive bytes at a random position with random data.
I then wrote three scripts to simulate 100 commits in the following three fashions:
the file is compressed with gzip in the repository
For each repetition: we decompress the file, then perform our edit, then recompress it and then check it in.
Final repository size: 9.6 MB
(This was better than I expected until I realized that because of the way gzip works, the bytes before the random edit (half the file, on average) will be identical to those of the previous version, even after compression.)
the file is not compressed in the repository
For each repetition: We simply perform our edit and then check in the changes.
Final repository size: 5.1 MB
the file is imported from scratch every time
For each repetition: we copy the binary (not using svn copy) to a new file, edit this copy, add it and commit the changes. This is equivalent to an import since there is no historical connection to the previous copy of the file.
Final repository size: 403 MB
Just to give you a feel for Subversion's server-side compression, I repeated this test, only this time I compressed the binary files on the client side before adding and committing them each time.
Final repository size: 392 MB
So, whatever subversion is doing, it appears to about as good as gzip.
Your questions make it sound like you're assuming that compression on the client side will help you. It may very well not do so.
In my experience it's only worth doing when:
压缩文件实际上会增加 SVN 存储库占用的空间。
为什么？ SVN 服务器尝试仅存储二进制比较产生的增量。 因此，通常只需要存储文件中已更改的部分。
然而，如果您压缩文件，那么最轻微的改变就会完全改变压缩结果。 每次提交时，SVN 服务器都需要存储完整的压缩文件，而不仅仅是更改的部分。
Compressing files will actually increase the space taken by your SVN repository.
Why? The SVN server tries to only store the deltas resulting from binary diffing. So normally only the parts of the file that were changed need to be stored.
If you compress the files however, then the slightest change will change the compression result completely. The complete compressed file will need to be stored by the SVN server for each commit, instead of just the changed part.