Tortoise svn checksum mismatch while updating
If you screw up your repository by following these steps, don't blame me.
This worked for me, if it doesn't work for you, try one of the other links above. If you're paranoid enough, getting into this situation in the first place (most likely a corrupted block on your drive) won't be that scary because you keep your tree checked out on multiple machines.
Directly putting back the text that was changed didn’t work for me.
I don’t know exactly how checksums are calculated, but it could be that they’re based on the contents of the file plus some meta-data (like the last modified date) or else I just missed some of the changes.
A benefit of my way over other procedures I’ve seen described is that I didn’t have to do anything special to get back to a state where I could commit the latest changes I had made.
After doing the above, SVN told me I had changes to commit. Ominous disclaimer: what I am describing worked for me, for text files. It should work for binary files, but I haven’t personally tried it.
There are a number of hits when you go searching for this problem, some of those workarounds may work better for you - this is just what worked for me.
An adage you'll hear from snotty slashdotters is "if you only have one backup, your data's not that important." and if you believe dire predictions there's no substitute for multiple, geo-redundant backups. In my examples I'm going to use abcd1234 for subversion's expected checksum and 1234abcd for the actual, and to indicate the corrupted file.
It's not immediately clear when you see that error which file specifically is causing the problem.
Before committing (saving) a file, SVN compares the latest revision of the file in the repository with the corresponding, locally saved, latest revision. If the checksum for a file changes, you know it has been altered.
Once you change a file, it’s really hard to get it back to its original state for the purposes of this check.