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

Re: Solving Large Repositories...

From: David Kastrup <dak_at_gnu.org>
Date: 2007-08-21 11:12:16 CEST

Ryan Schmidt <subversion-2007b@ryandesign.com> writes:

> On Aug 20, 2007, at 06:29, Adrian Marsh wrote:
>> When a repos becomes very large, are there any "maintenance"
>> procedures
>> to follow to archive away the "useless" data and reduce the size?
>> Eg, I've a repos, now 12Gb in size, but its working copy is 300Mb, 1
>> user, 50 revisions.
>> Now in a few months/years time the original data of early revisions
>> may
>> be worthless (say from revision 10 and before).
>> I'm guessing that I'd have to create a new respos, transfer 10+
>> into the
>> new one, and then re-point all the clients to the new repos - but that
>> sounds like a nightmare (clients being out of sync, having to re-check
>> out the data again etc)..
>> Surely theres an easier way?
> I don't think there's an easier way. Repositories are designed to
> store all data and never forget it. Coercing them to do otherwise is
> difficult, and somewhat on purpose.

Try git. As an example, the git repository for Emacs has 89033
revisions, a working tree size of 96MB, and a repository size of
170MB. So for the price of two Subversion checkouts, you get the
entire development history locally and can work with it off-line.

I am versioning software releases with git for some software of ours,
something like 300MB. There have been about two dozen releases up to
now, and the repository is still smaller in size than a single

As a downside, making git forget about checked-in material in a way
that actually releases the reclaimed disk space is very hard to do.
While there are tools allowing you to weed through a branch and remove
mistakenly checked in subdirectories, garbage-collecting afterwards
tends not to do anything impressive: git keeps a variety of "reflogs"
around that make it possible to recover from pretty much every mistake
by accessing branches, files, commits to any state in the last 90 days
or so. It is quite complicated to make it forget about some piece of
local history for good right away. It is probably easier cloning the
repository instead, and throwing the old one away.

David Kastrup
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 21 11:10:21 2007

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.