[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

revs files growing over time, relatively

From: Trevor Schaffer <TrevorSchaffer_at_smarttech.com>
Date: Wed, 28 Sep 2011 07:57:35 -0600

Server: Fedora Core 13 64-bit
SVN: 1.6.16 running on Apache 2.2.16

We have a repository that currently is in the 128K revision count, and is now standing at 40+GB in size. Over time it's been growing faster, and we noticed a trend on svn copies... the db/revs/* files are getting bigger over time.

After cracking one open, and another random commit, I saw that the commit entry not only lists information about the current path and it's siblings, but it also enumerates all parents, and their siblings as well... all the way to the root. This is a big issue for us, as we do a lot of build tagging, which means that every build tag commit lists the other thousands of build tags as well, which is why they are growing over time. At the current size of 600KB/commit for a single svn copy into our /tags area, performing 20,000 commits covers about 12GB of size, which I think is quite significant. Truthfully, probably 30+GB of this repo is just svn copies worth of commits.

Anyways, I'm trying to look for a solution to this, as we're starting to run out of room on the server it's on (we have many other repositories, which have grown from 100GB 9 months ago to 160GB now).

There are two questions that I have:
1. Is there any way I can recover the space and trim down the repo?
   a) svndump + filter. I can filter out the tags, but there are legitimate tags we need to keep (release tags)
   b) start a new repository. Like the first, but it means we have to keep the old one around read-only.
2. What is the best strategy for keeping the repository optimized?
   a) more layers in our tags/ folder structure to keep those commits a little smaller.

If anyone has any idea on what we can do with this, I would appreciate it.

In the meantime, I'm going to try to dump+load the repo in the hopes that there were some optimizations in svn 1.6 that will help. We've had this repo running for nearly 5 years, since svn 1.4.

I will also try out svn 1.7, but I don't know how soon we can get that into production. We are relying on Subversion Edge, so it can switch when that becomes live.
Received on 2011-09-28 16:00:58 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.