svn repository growing out of control because of builds

Question

I have a problem with my repository size, my repository grows out of control because at one point our project group decided to keep our builds in svn as well, each binary is around 30 MB, daily backups of the repo is taking 4-5 GB's after couple hundreds check in. It is getting quite difficult to take a backup of the repo and copy it to a network place where it is backed up everyday.

• What are the best practices to keep a backup of every build?

• Can I create a svn commit trigger that zips and copies the build somewhere instead of putting it to svn?

• How can I shrink my repo size?

• Can I get rid of some old binaries with svn commands?

Answer 1

What are the best practices to keep a backup of every build?

Do not do it. SVN (and all/most other Version Control Systems (VCS)) is designed to efficiently store textual documents (source code) by using/storing diffs. This does not work for binaries.

Can I create a svn commit trigger that zips and copies the build somewhere instead of putting it to svn?

Probably, but it is a major hack that (probably) needs to be done on each computer that has a checkout pf the repository. If you want to retrieve these again zips when you checkout the repository, it becomes even more bothersome.

How can I shrink my repo size?

Can I get rid of some old binaries with svn commands?

Once you committed something to SVN (and most other VCS) it stays, you cannot modify history. That said, you can create a new repository can copy all changes to it (there are some tools for it, to keep the commit messages). Maybe it is possible to recommit everything (without the builds) and use that repository from then on. (Make sure all project partners checkout the new repository to prevent problems)

As you noticed, storing all derived files (builds) in a VCS is 'not-a-good-thing'. For reproducibility, you can store build info, like version numbers of the used tools, instead. So it is always possible to rebuild a specific build if required.

Use a shared location that only contains the newest build so all project partners are able to see/try this newest build.

But, do not store it in a VCS anymore!

Answer 2

What are the best practices to keep a backup of every build?

Use correct tools for every task. Source control can manage build's artifacts, but - only poorly. Use artifacts manager for this job

Can I create a svn commit trigger that zips and copies the build somewhere instead of putting it to svn?

Yes, theoretically in hooks you can do anything (build, archive, deploy), but (again) special tools can do it more easy and smoothly for end-user (read "Jenkins", "Maven")

How can I shrink my repo size?

Create dump, kill unwanted revisions in dump, restore polished dump

Can I get rid of some old binaries with svn commands?

You can't do it with client-side tools, only with svnadmin-|dumpfilter-hacking dump