On Nov 12, 2004, at 8:29 PM, Matthew England wrote:
>
>> For my use, this is the only serious drawback of SVN compared to
>> CVS--serious
>> enough that I'm forced to keep CVS around for these files,
>> unfortunately ...
>
> So CVS apparently handles these "undiffable" files (or simply large
> binary files) differently? How so? Does CVS allow one to delete
> unneeded revisions of a file (when Subversion does not as per your
> description below)?
When you commit a new version of a binary file to CVS,
- the client sends the entire file to the server
- the server stores the entire file.
If you look at the corresponding RCS file in the CVS repository, it's
just a concatenation of every full version of the file.
When you commit a new version of *any* file to SVN (text or binary, svn
doesn't distinguish),
- the client sends only diffs to the server
- the server stores the diffs (details vary, depending on BDB vs.
FSFS back-end)
But as Glenn said, the problem is that sometimes a binary file is
already compressed, or changing the binary file results in nearly every
byte in the file being altered. When that happens, Subversion ends up
doing just as much work as CVS. The 'diff' being sent is as big as the
file itself, and so is the diff being stored.
So in general, SVN is more efficient than CVS when it comes to
transmitting and storing binary files. In certain edge cases, it's
equally inefficient. It's never worse.
Glenn's objection is that an RCS file is 'hackable' by hand... that you
can manually hack out old versions of a file (if you really know what
you're doing.) A subversion repository has no way of losing data,
ever... it's a database that's not hackable. The only recourse is to
[dump | filter | reload].
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 13 03:58:17 2004