SVN optimizations to keep large repositories respo

问题:

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.

回答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).

回答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.

回答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.