[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: Russ <rsivak_at_istandfor.com>
Date: 2006-11-10 03:22:49 CET

Personally I think svndumpdfilter needs to become part of svnadmin so that it's able to move between revisions. For example, I was trying to extract one subfolder with history into its own repository, but since its been moved around a lot... I had to write a whole page full of command line arguments just to get it to do that... It kept failing because if I only include the subfolder and it was copied from another folder and that folder was not in the list, it kept failing. I think if you include a path, it should be able to keep other paths that it was copied from in as well.

Russ
Sent wirelessly via BlackBerry from T-Mobile.

-----Original Message-----
From: "Jared Silva" <jayrod@gmail.com>
Date: Thu, 9 Nov 2006 16:50:44
To:users@subversion.tigris.org
Subject: Re: Repository growth

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 Fri Nov 10 03:23:27 2006

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