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

Re: Subversion migration problems

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2004-01-16 18:02:33 CET

dannys@changind.com writes:

> I just tried a load/verify into a 0.36.0 repository. However, I'm still
> getting checksum errors:
>
> * Verified revision 387.
> * Verified revision 388.
> * Verified revision 389.
> * Verified revision 390.
> svn: Checksum mismatch on rep '40t':
> expected: a69e82ef100f59f61c42b5ae29e67327
> actual: 25fe5e08dfce08fce2712861e7cfca1b
>
> I have a question though. I don't know if the original dump'd
> database database is corrupted or not (like I said, I'm getting
> non-identical dumps). But regardless of that, should loads report
> an error about the dump as it's reading? Instead of loading a
> corrupted database only to find out about it on a verify/checkout?

If 'svnadmin load' has checksums in the dumpfile against which to
verify data integrity, it will report errors if such data integrity
problems are found:

   <<< Started new transaction, based on original revision 1
        * adding path : file-1 ...subversion/libsvn_fs/dag.c:1333: (apr_err=200014)
   svn: Checksum mismatch, rep '1':
      expected: d3b07384d113edec49eab6238ad5ff00
        actual: d3b07384d113edec49eaa6238ad5ff00

Of course, it can only do this is your dumpfile has checksums in it
(older versions of Subversion didn't provide these).

That said, if you are getting checksum errors from 'svnadmin verify'
after your load has completed (irrespective of whether or not the data
in your repos is what you *meant* to have in there), then your new
repos has again corrupted that data.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 16 18:03:30 2004

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.