That matches what we've seen as well. We store a lot of MS Access
databases (.MDB files).
Under the old system (VSS+SourceOffSite), every time we had to check-in
a copy of a 200MB MDB, all of it would be transmitted and the new
revision would add 200MB to the repository. So we were forced to pack
the MDBs into ZIP files prior to committing them. Which was a PITA, but
shaved our sizes by 90% typically. So to commit a 200MB MDB, typically
required shoving 20MB across the wire and increased the repository size
by 20MB... even if we had only changed a handful of records in the MDB.
With SVN/TSVN, we no longer bother packing the MDBs in ZIP files. Nor
do we worry about small changes and frequent commits. The first version
of a 200MB MDB will grow the repository by 66-100MB (figure either 3:1
or 2:1 compression by the SVN engine... we haven't tested). After that,
figure commits are related to the amount of change within the MDB. If
we only changed a handful of records and didn't do something silly like
compacting the MDB afterwards, the commit might only be 1MB worth of
traffic.
In summary, between the binary diff algorithm and only shoving changes
across the wire, our bandwidth consumption when dealing with MDBs has
gone down drastically. And the repository grows at a sane pace rather
then the increased pace of storing ZIP files.
Of course, if the content of the binary files are already compressed in
some fashion, you'll likely not see much gain from sending only diffs
across the wire. (Files like JPGs, TIFFs, zipped up XML files, ZIP
files, .tar.gz or .tar.bz2.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-11 22:18:26 CET