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

Re: Abnomal behaviour: svnadmin dump - invalid dump or not?

From: <kfogel_at_collab.net>
Date: 2005-08-04 21:46:56 CEST

Marcus Mikolaiczyk <marcus.mikolaiczyk@carmedialab.de> writes:
> Thanks Karl,
>
> > Why do these dump files have different names ("...LaRa_EOL...") than
> > the ones given in your original 'svnadmin dump' commands? It appears
> > there are some steps in between that you're not showing us; perhaps
> > they are significant.
> Nope, it is just a fault from my side, I just want it to keep a simple
> as possible and renamed LaRa_EOL to repos in the mail, but forgot to
> rename the second part (the ls output) of the files. The repository is
> named LaRa_EOL and the svnadmin dump command hab been on this. So the
> Setps had been:
> 1. Move the Repository so that no one could check in or check out things
> to keep the revision.
> 2. use svnadmin dump to dump a full revision
> 3. use svnadmin dump to dump revs from 421:526 - for reimport
> 4. use svnadmin dump to dump revs from 510:526 - for testimport>
> >
> > If you were using the --deltas option, then this behavior would be
> > possible, albeit unlikely. However, without --deltas, this doesn't
> > seem possible to me.
> >
> I didn't use it . Using this option creates a faktor of 4!
> 864835816 2005-08-04 11:55 SVN.LaRa_EOL.dmp
> 275645857 2005-08-04 12:33 SVN_421-526.LaRa_EOL.dmp
> 819678954 2005-08-04 21:02 SVN_510-526.LaRa_EOL.dmp
> 811535000 2005-08-04 21:11 D_SVN_510-526.LaRa_EOL.dmp # --delta option
> 207931547 2005-08-04 21:12 D_SVN_421-526.LaRa_EOL.dmp # --delta option
>
> Realize this factor 4 by 200MBytes !!!
>
> > I suspect the answer to my first question may have something to do
> > with this strange behavior, however :-)...
>
> Sorry again this is not the case, as above stated, it was my fault in
> changing the repos name in the mail. So I won't confuse you in the rest
> discussion
> The command history was:
> 905 svnadmin dump LaRa_EOL > /tmp/SVN.LaRa_EOL.dmp
> 908 svnadmin dump LaRa_EOL --revision 421:526 >
> /tmp/SVN_421-526.LaRa_EOL.dmp
> 909 svnadmin dump LaRa_EOL --revision 510:526 >
> /tmp/SVN_510-526.LaRa_EOL.dmp
> 910 ls -l /tmp/SVN*.dmp
> 911 head /tmp/SVN_421-526.LaRa_EOL.dmp
> 912 head /tmp/SVN_510-526.LaRa_EOL.dmp
>
> So no magic at all. I also tested a different repository which behaves
> 'normal'. Small rev range (20) results in small dumpfilesize. Big rev
> range (100) results in bigger dumpfilesize. But not with LaRa_EOL.
>
> head SVN* #seems to be correct.
> ==> SVN.LaRa_EOL.dmp <==
> SVN-fs-dump-format-version: 2
>
> UUID: 4af0156d-9fde-0310-881f-e7f1d550fd13
>
> Revision-number: 0
> Prop-content-length: 56
> Content-length: 56
>
> ==> SVN_421-526.LaRa_EOL.dmp <==
> SVN-fs-dump-format-version: 2
>
> UUID: 4af0156d-9fde-0310-881f-e7f1d550fd13
>
> Revision-number: 421
> Prop-content-length: 128
> Content-length: 128
>
> ==> SVN_510-526.LaRa_EOL.dmp <==
> SVN-fs-dump-format-version: 2
>
> UUID: 4af0156d-9fde-0310-881f-e7f1d550fd13
>
> Revision-number: 510
> Prop-content-length: 126
> Content-length: 126
>
> Kind Regards Marcus

Okay. Then I'd really like to understand what's going on... Oh, one
possibility is that there were some major copy operations that
happened somewhere between 421 and 510. Since the first revision
always has to be dumped in fulltext, I think those copies would show
up as just copies in the 421-526 dump, but as fulltexts with copy
history in the 510-526 dump. This is just off the top of my head, I
haven't tested this.

Could you post the output of 'svn log -v' on your whole repository?
If the output is large (greater than 10k, say), just put it up at a
URL so we can look at it.

Thanks,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 4 22:42:44 2005

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.