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

Re: predict disk space reduction while deleting a part of the repository

From: Talden <talden_at_gmail.com>
Date: 2007-12-19 20:51:11 CET

> > Is it possible to predict how much I can reduce the whole repository (in
> > bytes) by deleting some branches from the repository. I guess this
> > should go somehow over the db logs but I have no idea how.
>
> I can confidently predict that you will save precisely zero bytes (in
> fact it will rise by a very small amount). ;-)
>
> There is no obliterate command in subversion; deleting a branch merely
> marks it as being deleted. All of it's history is preserved in whole
> (in a fairly efficient compressed format).
>
> The only [current] way to reduce the size of a repository is to use
>
> svnadmin dump | svndumpfilter | svnadmin load
>
> and recreate the repo from scratch (minus the filtered revs). This will
> unfortunately invalidate any existing working copies...

And my understanding is that, in certain cases, obliterate can
increase the amount of space used...

If an 'obliterated' path is a common ancestor of 2 or more retained
paths then those would have been cheap copies but would now become
'full-text' entries in the repository using up more space.

Though there are exceptions I wouldn't consider obliterate for space
reasons unless the space saved is significant. Also remember that if
the revision numbers change or any working copies are referring to
paths that are obliterated then those working copies will need to be
checked out again.

--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Dec 19 20:51:35 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.