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

shared checkout of large binary files?

From: Chad Dombrova <chadrik_at_gmail.com>
Date: Fri, 2 Jan 2009 17:27:24 -0500

I'm looking into the suitability of SVN for performing revision
control on many large binary files, but i'm concerned about the
massive waste of disk space that will result with the standard
"working copy" paradigm.

Here's a description of our scenario:

- the binary files will be checked out to hundreds of working copies
on a centralized server
- the total size on disk of the binary files will total several
gigabytes per working copy
- each working copy needs independent control over which revisions of
the binary files are checked out, however most will contain the HEAD
revision.
- very few of the owners of these working copies actually need to
modify the binary files, most simply need read-only access to the files.

when using SVN it is normal for each working copy to contain largely
the same set of files, but in our case, these files are very large and
it is not feasible or efficient for us to have terabytes of redundant
data checked out to our server. what i would really like to see is
the ability to check out a symbolic link to a shared, read-only copy
of the file, stored in some scratch space on our server. in this way
all of the working copies that have checked out a particular revision
of a file will share one copy. i'm assuming that this feature does
not exist, but is it something that others might find useful?

does anyone have any advice on how SVN could be used to efficiently
handle a scenario like this?

thanks,
chad

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1000116

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-01-05 13:54:41 CET

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.