> On Thursday 09 November 2006 22:46, Mark Johnson wrote:
> >>> The dump-filter-reload approach works, with some hiccups, but it
is
> >>> expensive in terms of time and space.
> >>> For me, the time cost was filtering the 19GB through svndumpfilter
> >>> prior to re-loading.
> >>> And yes, there is a lot of branching and tagging history in the
> >>> repository.
>
Ulrich Eckhardt Wrote:
> Now, the storage increase by the amount of changes (which sounds
reasonable)
> so if you don't want so much growth, why not reduce the number of
changes?
>
Well, I wish it were that simple, but we have dozens of repositories,
and hundreds of users.
I don't see how I can reduce the number of changes being made.
One of our teachings is for the developers to "Commit early and often".
Unfortunately one cause of our bloat is that some people in our
organization have
made the mistake of adding files instead of copying them (expensive
versus cheap operations).
I want an efficient way to clean up after these mistakes.
> I assume you are not making the fault of e.g. checking in generated
files
> with every development revision or something like that. Since those
are
> often large and hard to diff, that would be a big (and IMHO
unnecessary)
> overhead that bloats up your repository.
Of course I am in agreement with you on this point.
Unfortunately, the fact is that some of my users have been doing just
that.
As an administrator, I need to come in after the fact and clean up the
mess.
How do I most effectively monitor the repository health in general?
How does sourceforge (for example) keep repositories healthy?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 10 19:15:08 2006