Re: Handling directories of large files

subversion@jelmail.com wrote:
> Hello, I'm after some "best practice" for handling directories of large
> files.
>
> I have a repository with a directory that contains tarballs of various
> packages I use. This directory is huge. If I wish to add to this directory
> I have to check out the entire directory, add files to the working copy and
> check back in. Is there a better way to do this? Typically the files here
> are added but never modified.
>
> Similarly, I have a directory containing iso images. This directory also
> contains build scripts that make the iso images using stuff I have
> elsewhere in subversion. To change the build scripts I have to check out
> the entire directory, make my changes to the build script working copy and
> check back in. This can mean checking out gigabytes of data just so I can
> change one line of script. Some files here need to be modified, but the
> vast majority don't.
>
> My repo looks like:
>
> repo
> iso
> build_script
> readme
> iso_release1.iso
> iso_release2.iso
> iso_release3.iso
> packages
> package1.tar.gz
> package2.tar.gz
> package3.tar.gz
> package4.tar.gz
> ...
>
> Perhaps I am doing this with an incorrect repository structure and I
> misunderstand how svn should be used. Any help and guidance would be
> greatly appreciated.
>
> Many thanks,
> John
>
>
You don't need to check out a folder to add files to it; you can import
new files to an existing folder.

Each release could be in its own separate directory, so you would have
something like this:

repo
    iso
        release-1
            iso_release1.iso
        release-2
            iso-release2.iso

etc.

We consider the build scripts to be source code so they are maintained
with the source code, not the release. I would suggest you move your
build scripts to the source project tree.

For most users Subversion may not be the best place to put release
binaries. The main issue is that once files are put into Subversion,
they are difficult to remove. Unless you need to track and audit changes
to the binaries, it might be simpler to store the releases on a shared
network drive or content management system. It really all depends on
your requirements for accessing, tracking and maintaining releases.

--
John Waycott
Hypercom Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org