> From: Stefan Sperling [mailto:stsp_at_elego.de]
>
> By design, the handling of checksums is sane.
> Checksums are stored in the repository, and are calculated by the
repository
> layer. A client can only tell the repository what it expects the checksum
to be.
> When the client sends content, the repository calculates the content's
> checksum and compares that to the expected checksum. See also
> http://svn.haxx.se/dev/archive-2010-07/0426.shtml,
> where Mike Pilato explains this in detail. [That thread is about a commit
I
> made that added property content checksums to dump files. The commit
> was later reverted because it's just as cheap to compare the actual
property
> contents since we treat property content as strings (but the loader
doesn't
> do that, yet).]
>
> I'm not sure what svnadmin verify is doing wrong in your case.
> But I know that there are corruptions it doesn't detect, and we're
planning to
> improve this situation:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3706
Actually, there is another option. Perhaps "svnadmin verify" is doing
exactly the right thing ... checksums are stored in the repo, it calculates
checksums and verifies them all. Perhaps it's right. Perhaps we're only
*assuming* the corruption is at the slave side, while the corruption is
actually at the master. The only thing I know for sure is that there's a
checksum mismatch between master & slave, for a specific file, beginning at
a specific rev... Maybe the master is the one who's wrong.
Problem is, I don't know of any way to check, and determine which side is
wrong. It's very labor intensive to checkout all the revs from the slave,
and from the master, and diff them all, to see if any other files are
"corrupt." But that is my plan, if I can't come up with a better idea.
Received on 2010-11-12 02:41:51 CET