Hi Bob,
I put my drive in an enclosure and loaded it as you suggested, piping the
dump straight into the repo on the new machine (it's a laptop so I can't
just install the drive). It worked without a problem, so something was
going screwy with the dump file somewhere.
Cheers,
Ian
On Saturday, February 8, 2014 3:37:58 AM UTC+13, Bob Archer wrote:
>
> Are you streaming to disk, then loading from disk? You might want to
> just directly pump the dump stream into the load. Just an idea.
>
>
>
> *From:* Ian Wiles [mailto:ian.alexa..._at_googlemail.com <javascript:>]
> *Sent:* Friday, February 07, 2014 3:04 AM
> *To:* subversi..._at_googlegroups.com <javascript:>
> *Cc:* Ian Wiles; us..._at_subversion.apache.org <javascript:>;
> m.sc..._at_codesys.com <javascript:>
> *Subject:* Re: svndumpfilter woes
>
>
>
> Hi Markus,
>
>
>
> Thanks. I ran verify and everything passed. which is good, so I assume
> it's recoverable somehow. I'm going to try a fresh dump and see if that
> helps. For now I've loaded the last few revisions which is enough for me to
> be getting on with until I figure out how to stop svndumpfilter ignoring me.
>
>
>
> Cheers,
>
> Ian
>
> On Friday, February 7, 2014 8:06:49 PM UTC+13, Markus Schaber wrote:
>
> Hi, Ian,
>
> I think that you should try to check / consider two scenarios:
>
> - Repository corruption: Maybe the existing repository contains
> Inconsistent data for some reason. You should try to check
> "svnadmin verify" on the repository, this will find most
> kinds of corruption.
>
> - Hardware failure: The data reading from the harddisk or your
> RAM may be broken, and occasionally flip some bits. This may
> be the case on the existing server, as well as on the
> destination machine.
>
>
>
>
> Best regards
>
> Markus Schaber
>
> CODESYS® a trademark of 3S-Smart Software Solutions GmbH
>
> Inspiring Automation Solutions
> ________________________________________
> 3S-Smart Software Solutions GmbH
> Dipl.-Inf. Markus Schaber | Product Development Core Technology
> Memminger Str. 151 | 87439 Kempten | Germany
> Tel. +49-831-54031-979 | Fax +49-831-54031-50
>
> E-Mail: m.sc..._at_codesys.com | Web: codesys.com | CODESYS store:
> store.codesys.com
> CODESYS forum: forum.codesys.com
>
> Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner |
> Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
> Von: Ian Wiles [mailto:ian.alexa..._at_googlemail.com]
> Gesendet: Freitag, 7. Februar 2014 06:29
> An: subversi..._at_googlegroups.com
> Cc: us..._at_subversion.apache.org; tscho..._at_am-soft.de
> Betreff: Re: svndumpfilter woes
>
>
>
> On Thursday, February 6, 2014 10:42:24 PM UTC+13, Thorsten Schöning wrote:
> Guten Tag Ian Wiles,
> am Donnerstag, 6. Februar 2014 um 09:39 schrieben Sie:
>
> > It's a problem since trying to load the dump in the new
> > repo is failing on some binary files so I can't load the repo at
> > all.
>
> If that's the only reason you want to get rid of the files in your
> dump, you may provide the error message and fix this error because SVN
> should be able to load even large binaries.
>
> > svndumpfilter exclude --pattern "*.ncb" < orignal_dmp.fil >
> filtered_dmp.fil
>
> May this get translated to /*.ncb only and therefore doesn't get
> applied recursively? Maybe you need something like **/*.ncb.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>
> --
> Thorsten Schöning E-Mail:Thorsten.Schoening_at_AM-SoFT.de
> AM-SoFT IT-Systeme http://www.AM-SoFT.de/
>
> Telefon...........05151- 9468- 55
> Fax...............05151- 9468- 88
> Mobil..............0178-8 9468- 04
>
> AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
> AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
>
> Hi Thorsten , thanks for the response.
>
> My main concern at the moment is just loading the dump file and the errors
> are preventing that. It would be good to filter out the binaries, but its
> not a priority just now.
> The error I get is a hash checksum failure, and only on binary files:
>
> * editing path : MyFile.ncb ...svnadmin: E200014: Checksum mismatch
> for '/MyFile.ncb':
> expected: ab27603550fc52585bd6e98c6d7d0b6c
> actual: f52642a0cc3186a7da837569fcde32a1
>
>
> A re-dump didn't seem to help much. In fact I split up the dumps by
> revision in a bid to fix the problem, but then I got a failure earlier in
> the repository around revision 2xx. In fact whatever dump file I take seems
> to fail to load at some point due to a binary file checksum mismatch, which
> is pretty frustrating.
>
> Cheers,
> Ian
>
Received on 2014-02-22 10:19:01 CET