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

Re: admin driven deltification

From: Mike Mason <mgm_at_thoughtworks.net>
Date: 2003-11-14 18:01:22 CET

C. Michael Pilato wrote:

>3. Finally (and this is kinda hard to explain), the longer you go
> without running deltification, the larger your repository gets, and
> administrators should understand that deltification does *not*
> immediately reduce the footprint of your repository. That's right.
> If you run 'svnadmin deltify' on your repository, you can expect it
> *not* to shrink. What happens during/after deltification is that
> because you are now storing less data in a database file than you
> were before, Berkeley DB simply marks a bunch of its internal
> pages as "free", and those are the first to be re-used when
> Berkeley needs to store more data in the repository.
> This is why I made 'svnadmin load' go ahead an deltify every each
> loaded revision. When I didn't, you had a repository that was
> *huge* on-disk -- so huge that if you then deltified the whole
> thing, and then instituted a per-commit deltification policy, you
> might *never* actually make use of all that extra allocated space
> (at least not for something like 3x the number of loaded
> revisions).
This is the same kind of behaviour that Perforce exhibits -- db space is
used up, the db gets fragmented etc, and a full dump/recreate generally
allows you to reclaim some disk space. Being a big Perforce fan, it's
almost reassuring to hear this kind of thing about Subversion.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 14 18:03:38 2003

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

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