D. Alan Stewart wrote:
> Warning! I'm a svn newbie. I so have some user-level experience with
> cvs.
>
> I'd like to use svn to maintain histories of some large binary files
> (Parallels virtual hard disk images). they are typically 10-30 GB
> each. I have installed the svn server and client on my OS X system.
> The working files are on my laptop's boot drive, and the repository
> on a 160GB secondary Firewire drive that I plug in when I'm at home.
>
> However, I cannot even import one of these files because 'svn
> import' fills up all available disk space on the boot drive. The
> available free space on this drive is less than the size of the file
> I want to import. Is there any way to direct where svn writes its tmp
> files? From earlier postings in this list I gather that svn writes
> them in the source directory. I have plenty of space on the secondary
> drive if I could point svn to some location there.
>
> I'm also wondering if I *temporarily* move data of my boot drive to
> accomplish the initial svn import, will I have the same problem when
> the time comes to commit changes?
First: Buy another drive, seriously. If you're going to deal with files
*THAT* big, you want a couple of hundred Gig to work with.
Second: If I were working directly with you, I'd want to slap you for
creating that disk image structure. Seriously, unless you absolutely need
disk images, you'll be much happier having a compressed tarball of the file
system itself and a "make" structure that generates and ungenerates the disk
image from the tarball, and vice versa. Disk images are notmally built of
mostly wasted space, since the blank or unused bits of the filesystem are
also in the disk image, and it makes them very awkward to work with.There's
an occasional reason to do it for things like VMWare disk images, but it's
messy to cope with and will explode the size of your repository, since your
binary check-ins are likely to be *HUGE* and there's no graceful way throw
out previous versions of a binary under Subversion.
Third. Compress the damn thing for storage and submission to Subversion!
Unless the image is realy jam-packed with binary data, you'll get a
reasonable compression benefit and help speed up your check-outs and
check-ins.
Fourth: I don't see any way for you to avoid the spare files in .svn at
checkout. It might be feasible to do an "svn export" and "svn import"
instead, but I see such other big problems for you with such big file
images, I'd urge you to sit down with someone else competent in your setup
and work out a way to shrink those.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 29 14:04:01 2006