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...@googlemail.com <javascript:>] > *Sent:* Friday, February 07, 2014 3:04 AM > *To:* subversi...@googlegroups.com <javascript:> > *Cc:* Ian Wiles; us...@subversion.apache.org <javascript:>; > m.sc...@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...@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...@googlemail.com] > Gesendet: Freitag, 7. Februar 2014 06:29 > An: subversi...@googlegroups.com > Cc: us...@subversion.apache.org; tscho...@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.schoen...@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 >
