Antwort: Re: Problem using subversion on a large repository

Hi,

        thanks for the answer ... now my results ..

                -> yeah you are right Repository size is right now:
7270760 K -> 7G

        I try hard to solve this Problem -> now I present my experience:

        1. this doesn't work:

                ->svnadmin dump -r $(svnlook youngest $OLD) $OLD |
svndumpfilter exclude mytags | svnadmin load $NEW

                the reason is to delete the huge "mytags" tree created
with "svn copy ..." with dumpfilter !after! "svnadmin dump"
                was unuseable slow because before deleting you have to
dump everything ~1TB (just a assuming) before you can filter

        2. the solution was to delete the whole tags directory first with:

                -> svn delete ....

                and than using the command above to create the new
repository, but i have to say:

                -> createing tags with "svn copy ...." is a design error

                nice for small projects but not useable in a big
environment !!!

        3. I just support the "oldstyle" position that

                -> svn dump OLD | svn load NEW

                should create a repository NEW with close the same size as
OLD

 
Freundliche Grüße

Andreas Otto
ISV13 - Systemverantwortung Leben
 
Telefon 0431/603-2388
Sophienblatt 33
24114 Kiel
 
VersIT Versicherungs-Informatik GmbH
Gottlieb-Daimler-Str. 2, 68165 Mannheim
Registergericht: Mannheim HRB 6287
Vorsitzender der Geschäftsführung: Claus-Peter Gutt

Felix Gilcher <felix.gilcher_at_bitextender.com>
22.10.2008 11:35

An
Andreas.Otto_at_versit.de
Kopie

Thema
Re: Problem using subversion on a large repository

Well, I hope you're missing a decimal point on this one:

> 7124552 G

;)

Anyways, how did you dump that single revision? The exact command
would be of interest. As far as I know, the dumpfile uses a diff
format as well, so the full dump should only be slightly larger than
the repository itself, not like 10 times the size. However, if you
dump only the last revision without specifying --incremental, it might
spit out the full data for the head revision, which would be each copy
for itself, no ancestry information taken into account.

Anyways, what are you trying to accomplish? You can just use svn
delete to remove unused branches/tags/parts of the tree. It will not
regain you any space, but as most of your stuff is a copy, your loss
is not really big. Copies only take a couple of bytes, they're cheap.
It's usually not required to clean a repository.

If you really want to go down the road of filtering out revisions, you
can alway pipe the output of svnadmin dump straight to dumpfilter and
then to a file, this would at least remove the parts you don't need.
As svnadmin dump does not alter the original repository, the risk of
damage is pretty much nonexistent - just keep the old repo around
until you've created and checked the new one.

cheers

felix

On Oct 22, 2008, at 10:45 AM, Andreas.Otto_at_versit.de wrote:

>
> Hi,
>
> my problem is using subversion in a large development project
>
> Just the numbers:
>
> 1 ~ 500 Software Packages with up to ~100 files per
> package
> 2. a lot of testig data
> 3. total size of a checkout is ~5G
> 4. HW SLES 10 with 32G memory + 2 quadcore
> 5. subversion default package in SLES 10 ->
> subversion-1.3.1-1.10
>
> the size of the repository itself is
>
> 7124552 G
>
> The problem to delete old (unused) source-trees using the
>
> svanadmin dump/load
>
> feature but i'm not able to even dump this repository because
> i have a lot of tags created with:
>
> svn copy
>
> and these tags have no space in the rep but seems
> to use a lot of space in the dumps
>
> a dump of a sigle revision piped into gzip 9 took
> 1 day and created a 80 G dumpfile
>
> the propblem is what I want to admin the repository for
>
> -> cleanup unused revisons / trees
>
> i need the dump/filter/load syntax because no other command
> is doing this job
> I don't even have enougth disk space to do this and
> recreating a new repository with the
> 80G gzip 9 single revision dump creates a repository with
> close this size
> (remember my current rep size is ~7G)
>
> -> How i can cleanup my rep ?
>
>
>
>
>
> Freundliche Grüße
>
> Andreas Otto
> ISV13 - Systemverantwortung Leben
>
> Telefon 0431/603-2388
> Sophienblatt 33
> 24114 Kiel
>
> VersIT Versicherungs-Informatik GmbH
> Gottlieb-Daimler-Str. 2, 68165 Mannheim
> Registergericht: Mannheim HRB 6287
> Vorsitzender der Geschäftsführung: Claus-Peter Gutt
>
>

--
Felix Gilcher
Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München
T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28
felix.gilcher_at_bitextender.com
http://bitextender.com/
Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever