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

Re: large db/revs files

From: olli hauer <ohauer_at_gmx.de>
Date: Tue, 04 Jun 2013 19:45:26 +0200

On 2013-06-04 16:30, Andre Harper wrote:
> Hi, all –
> I am not subscribed and would appreciate being explicitly Cc:ed in any
> responses.
> I am on a team that began using subversion near the end of last year.
> As a part of our process, we tag each successful run of our systems.
> This can mean thousands of tags for certain systems every six months.
> We’re having an issue with the db/revs directory size, which for all
> our projects currently exceeds 289G. We only use relatively small
> working directories containing less than a meg of text files; no
> binary files.
> In the archives, I found a mention that the db/revs directories are
> populated using xdelta, but there didn’t appear to be a solution to
> large file sizes at time
> [http://svn.haxx.se/users/archive-2011-08/0229.shtml
> ]. I was hoping someone may have found a work-around or solution.
> Would someone be able to:
> 1) suggest how to avoid this in the future
> 2) suggest how to reduce the current large files (if possible)
> Thank you.
> André Harper

Wow, how many revisions are this and what is the average size of the source (1MB)?

Even with a several thousands tags and plain text files there is a change to keep the repository small.

For example your files could be plain text files with
 - max 10 chars per line (good for xdelta)
 - containing only single line (bad for xdelta)
 - EOL style / white spacing changed during commit (bad for xdelta)
 - ....

With the worst case examples in mind you can inspect your sources and maybe find some improvements.

Have you looked direct on the server side to the repo ($repo/db/), where is all the space used?
 - rep-cache.db
 - revs
 - transactions (I've seen repos with several GB inside)
 - revprops
Received on 2013-06-04 19:46:05 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.