You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Chad Dombrova <ch...@gmail.com> on 2009/01/02 22:27:24 UTC

shared checkout of large binary files?

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@subversion.tigris.org].

RE: shared checkout of large binary files?

Posted by Bob Archer <Bo...@amsi.com>.
Have you considered creating a read-only repository that is outside of
the svn repository that is updated using hooks after each commit? Your
users could create sym links to that. Or just access it as a share or
mount it somewhere on their local PC... making sure that the group/users
only have Read permissions. 

Or, show your users how to export when they won't need to be doing
commits?

BOb

> -----Original Message-----
> From: Chad Dombrova [mailto:chadrik@gmail.com]
> Sent: Friday, January 02, 2009 5:27 PM
> To: users@subversion.tigris.org
> Subject: shared checkout of large binary files?
> 
> 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&dsMessageI
d=
> 1000116
> 
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe@subversion.tigris.org].

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

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].