Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
As odd as it seems, doing a full "svnadmin dump --deltas" of your
repository may in fact create a smaller dumpfile than dumping a
specific revision with "svnadmin dump -r REV".
(When not using --incremental flag.)
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
my goal was to filter out some unused repository paths using svndumpfilter
Question: Can I use the dumpfilter with "svnadmin dump --deltas" ?
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
kmradke_at_rockwellcollins.com
28.10.2008 16:50
An
Andreas.Otto_at_versit.de
Kopie
haisenko_at_comdasys.com, users_at_subversion.tigris.org
Thema
Re: Antwort: Re: Antwort: Re: Antwort: Re: Antwort: Re: Problem using
subversion on a large repository
Andreas.Otto_at_versit.de wrote on 10/28/2008 10:29:55 AM:
> thanks for your answer ....
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> If you want to do a full dump, use "svn dump --deltas REPOS_PATH >
out.dump".
> This will create a dumpfile that should be similar sized to the
REPOS_PATH
> directory. I have dumped thousands of multi-GB repositories, and never
> seen one larger than 3x the FSFS directory size.
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> if just the HEAD revision of the repository has a ~80G gzip 9 than overy
> other (flag) will produce a least
> more size than this ~80G gzip 9 file
No, if you just dump one revision, all tags will be expanded
to full copies since where they were copied from does
not necessarily exist.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Using -r will only dump the amount of data representing the
> files changed in that revision. It does not dump the whole repository
at
> the state of the revision. This size of a dumpfile does not make sense
> unless you did incorrect svndumpfilter commands in the past.
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> this statement has 1 error
>
> 1. with the -r option I get the whole snapshoot of the repository and
not the
> repository changes
> -> I check this ... I took the HEAD revision and got the total HEAD
revision back
> -> this was important to not lose data :^)
> -> but I loss the entire history :-(
Yes, sorry, I was describing the --incremental flag when used with -r.
(I've
never used -r alone, since it would most likely create huge dumpfiles
because all tags will be full copies.)
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Be aware, if you remove a path that had multiple tags, it will create
full
> revisions in each of the tags path. I'm guessing you may have done this
> previously which is causing your current problems.
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> this is wrong ... my first try to filter the repository
I was just guessing, since you were only including descriptions
of your commands, not the actual commands...
> I thing the last part of what you are saying is the right one ...
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> Dumping and filtering a repository can cause the repository size to
> grow significantly if you do not do it VERY carefully...
> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> this is what I have observed ...
> -> the VERY carefully was for me to delete all of the tags created by
svn
> copy ... first
Ok, I believe your problem is trying to use "svnadmin dump -r REV" with
a repository that contains a lot of tags. This will indeed create
full copies and inflate the dumpfile size since the dumpfile does
not have any past history to base the copied tags.
As odd as it seems, doing a full "svnadmin dump --deltas" of your
repository may in fact create a smaller dumpfile than dumping a
specific revision with "svnadmin dump -r REV".
(When not using --incremental flag.)
Kevin R.
Received on 2008-10-29 08:21:50 CET