SVN optimizations to keep large repositories responsive

Question

We happily use SVN for SCM at work. Currently I've got our binary assets in the same SVN repository as our code. SVN supports very large files (it transmits them 'streamily' to keep memory usage sane), but it makes everything SLOOWWWWW. I'm ok with slow asset versioning, but slow text operations isn't really acceptable.

Right now assets are under /trunk/release (side by side with a dozen /trunk/projects). Should we keep them in a separate repository? What other optimizations can we do? We have about a GB of assets and growing.

Mcmann

Answer 1

IMNSHO its better to keep each project in its own repository, if just for the purpose of keeping the revision numbers separate between them. If project foo hasn't been changed in six months, but project bar is in active development, why should foo's current revision number keep changing. The exception perhaps if the two are tightly couple (like they share a common library), but even then maybe the library should be its own project as well.

Are the binary assets ever changing at all or are they static? If they are static, maybe you don't want them in the repositories at all (just leave a small place holder in there).

Nomenclature

the SVN revnum is not project-specific, its repository-specific. Its a mistake in thinking that foo gets a new revnum - if nothing's changed in foo, it doesn't get a new revnum! The current revnum for foo is either 'HEAD' or the last revnum where project foo was changed. – Homebred

Answer 2

You didn't say what optimizations you use already. If you are using bsdfs, see whether switching to fsfs improves performance. If you have a large number of revisions, switch to a more recent version on the server, and convert the repository to the 1.5 format.

Bathos

Answer 3

probably the best answer you're going to get is to put your binary files into a separate directory and use the Spare Directory features to manage them - ie do not check out the files until you need them. Then all operations will occur on the source files and not the binaries.

Alternatively, you can use the same mechanism to commit or update - instead of updating your Working copy, you can use 'update to revision', and specify HEAD and a reduced depth, so the binary directory doesn't get updated (until you need to).

You can also 'svnadmin pack' your repos, which will improve server-side performance.

Homebred