Hi Steve,

quoted text
> In reading this I wondered how a svn dump of one of the
> repositories monitor would size.  If I were to check out the svn
> root of that repository, I would use well over 3TB of disk space
> to have that checked out, I filled my 750GB drive with about a
> third of it checked out.  About 256MB of code with thousands
> of tags and hundreds of branches.

I encountered this issue with my first attempt to validate the output of 
my dump conversion tool. My case wasn't as dire, 350GB would
have sufficed but I was working in a 160GB partition.
Checking out tags side by side is a sure way to fill your disk.

quoted text
> It looks like svnadmin dump defaults to dumping all data.
> Fortunately it has a delta option, which looks like it would be
> needed to dump this repository I am speaking of without filling
> up many hard drives.

The svn dump format is not quite that silly, even without deltification
it doesn't output blobs that are just an unaltered copy from a
previous revision.
Handling deltified dumps will greatly increase the complexity of the
import process. Blob content would have be computed from existing
blobs rather than simply passed through.

quoted text
> This might also be helped if the dumps are chunked into ranges
> for many thousands of commits as well, this would keep the files
> more manageable

Being able to handle a dump stream reassembled from such
piecewise dumps is an important feature which I haven't finished
implementing yet.

quoted text
> Just food for thought.

Thanks for the feed.

--
David Barr

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html