[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Any problems w/ very large (10-100MB) binary files?

From: Matthew England <mengland_at_mengland.net>
Date: 2004-11-13 04:10:20 CET

Hi Ben,

Thanks for the background info. That seems to be good to know.

At 11/12/2004 08:57 PM, Ben Collins-Sussman wrote:
>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].

I'm reading Glenn's "objection" differently. I'm hearing the "larger
picture" as the inability to delete unneeded revisions of a file. While in
many ways it sounds good that SVN will never "lose" data/revs...in some
cases it's bad.

eg, let's say I'm rev-controlling a lot of content/collateral for a
product-training class. Lots of documents, powerpoints, and even large
video files. Some of these video files are HUGE. 50MB or bigger, some of
them. If I have multiple revs of each one of those stacked up, all of a
sudden my server's storage capacity is taking a big byte (and maybe SVN
performance does, too?).

I'd like to go selectively delete some of the older revs of the video files
for I'm safe that I'll never need them again. They've almost completely
changed in content from one rev to the next (for various reasons: movie
resolution change, a reshoot, etc)--even though they are still addressing
the same thing and should keep the same name and logical revisioning scheme.

This is the problem I want to solve....and it's what I hear Glenn saying,
too. Maybe I'm simply not understanding things (either Glenn or the
SVN-specific stuff) correctly?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Nov 13 04:10:44 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.