Below is a thread that examines some of the issues with storing large
binary files:
http://svn.haxx.se/users/archive-2007-03/1165.shtml
From the testing I did (with Linux kernel tarball IIRC) subversion did
a pretty good job in many cases, although not as good as the xdelta
program could do.
As Phil mentioned, if you need to compress them, then using the
--rsyncable flag is important - a small uncompressed change can result
in a large change in the compressed output, which will defeat
subversion's delta algorithm. I did not try bzip2, but I would guess
that you would not get any addition compression from subversion. (the
repo size would grow by the size of each .bz2 file checked in.)
The conclusion that I came to was:
I also tried a few experiments with gzipped files, and found that gzip
with the --rsyncable flag did better than uncompressed by a small
margin, and that normal gzipping did much worse.
Doing your own experiment is easy (and the results may vary given your
type of blob.)
* set up new FSFS repo
* add a blob, then check in changed blobs
* Look at the size of the revision files in the repos (be sure to read
up on skip-revisions so you understand exactly how the delta is being
computed.)
Roy
On 7/4/07, Ph. Marek <philipp.marek@bmlv.gv.at> wrote:
> [Sorry for the non-reply. I'm not subscribed, just saw the thread while
> looking for something else.]
>
> gzip has (at least in debian) the parameter
> --rsyncable Make rsync-friendly archive
>
> In your case you could try to archive you tarfile with a common name,
> like "sources.tar" (uncompressed, or compressed with "--rsyncable").
>
> If you need the versions referenced, just make tags.
>
>
> For a new version just replace the file and re-commit (ie., no "add/remove"),
> so subversion should be able to see that there are only some differences.
>
> (That's what "--rsyncable" does - stop the compression at certain points, so
> that some other program can match the parts again.)
>
>
> HTH,
>
>
> Regards,
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 7 00:42:44 2007