On Sep 30, 2005, at 10:40, Jon Sporring wrote:
> We've recently converted a cvs repository into a subversion using
> cvs2svn and
> FSFS. We experince the following problem: The repository on the
> server is
> only 5.5GB, which is half the size of the original cvs repository
> 11GB, but
> when I checkout the trunk, then the resulting working copy is
> almost twice
> the size, 19GB, of the original checkout of the cvs repository.
> We do have
> large binary files, which we use as a method of file-sharing, and I
> realize,
> that this will cause the file to be present in the working copy
> twice: in
> the .svn directory and in the corresponding place of work.
> However, it would
> appear that the subversion repository uses compression; does anyone
> know of a
> simple way to enforce compression on the .svn directories or any
> other smart
> trick to reduce the size of the working copy?
A CVS working copy does not store a pristine copy of the checked-out
files; a Subversion working copy does. The advantange is that
Subversion can quickly create diffs, whereas CVS requires a trip to
the network, which can be slow. Subversion is constructed on the
philosophy that disk space is cheap and fast, and network bandwidth
is expensive and/or slow. For those who disagree with this idea,
there is currently no way of telling Subversion to behave
differently, although there are already feature requests open to have
the working copy pristine data compressed or altogether absent.
A Subversion repository is stored as a sequence of diffs against
previous revisions, and so is generally fairly space-efficient. I
cannot comment on how Subversion's repository storage algorithm
compares with CVS's.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Oct 5 12:53:00 2005