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

Re: Repository growth

From: Jared Silva <jayrod_at_gmail.com>
Date: 2006-11-09 22:50:44 CET

On 11/9/06, Mark Johnson <MaJohnson@corillian.com> wrote:
> How do other Subversion administrators manage (or prevent) excessive
> repository growth?
> I recently had to dump, filter, and reload a huge repository (19GB!!).
> Of course this was an extreme case, but it made me really wish I had the
> ability to "obliterate" revisions.
> See the entry for in the issue tracker for issue #516:
> http://subversion.tigris.org/issues/show_bug.cgi?id=516
>
> I recognize that this is probably a complicated problem to solve, but it
> also appears that most people feel it is a necessary addition to the
> Subversion administrator's toolkit.
>
> Here is some example situations (from my perspective):
> 1. people can develop patterns of use that, over time, will
> cause repositories to become huge
> 2. sometimes people commit sensitive data to the repository
>
> In the first situation, of course, training about the persistence of
> data in the repository helps.
> On the other hand, even smart, well-trained people can inadvertently
> commit garbage.
>
> The second situation is something that we must deal with from time to
> time.
> The dump-filter-reload approach works, with some hiccups, but it is
> expensive in terms of time and space.
>
> I'd like to hear other administrators solutions to monitoring and
> containing repository growth.
> For instance, since sourceforge now hosts a lot of subversion
> repositories, what are their tricks?

Personally, I would like more advanced svn admin commands than just
svndumpfilter to modify a repository.

For example, a user "cp file1 file2" and "svn add file2" instead of
"svn cp –r HEAD file1 file2". The copy history is not preserved in
the repository, but really, it should be. I know modifying a
repository sort of goes against the whole version control and version
history scheme, but there are cases where the repository itself is
inaccurate and it should be able to be fixed "behind the scenes".

Another example, when I "svn mv" or "svn cp" I sometimes forget –r
HEAD to specify the revision to move/copy from. When I forget, the
commit uses the head revision of the repository instead of the head
revision of the source file. I would like to correct this number in
the repository, again to correct inaccuracies in the history.

P.S. Personal opinion!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 9 22:51:41 2006

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.