subversion checksum mismatch - easy workaround
Stamped: February 14th, 2007
i got this (apparently a corrupted repository) tonight, and found that the workarounds posted on the interweb didn’t work for me - because i didn’t have a representations file to dump. (are those workarounds for an older SVN?)
but the fix was relatively simple, and i figured if it saves some other folks from messing around then why not throw the relevant factoids at the giant google brain and see if some stick on under SUBVERSION gives me a CHECKSUM MISMATCH how do i FIX THIS, HELP?
here’s how we check out a second copy of the relevant directory, and swap it in. optionally then copying over any other corrupted files etc. you may need to add salt or sugar to suit your specific situation (ie, in my example, there are no subdirectories blocked by the corrupted file)
- PROBLEM: i can’t check in the file ‘lib/objects/blah.ext’ because i get the error:
svn: Checksum mismatch for ‘.svn/text-base/blah.ext’; expected: ‘f8d45250f7df5561635854165862fdd8′, actual: ‘644f85c4befa671150c5c6ec5fad9885′
- first i checked in all the files that didn’t complain
- cd lib/objects # go where the corrupted file is
- grep url .svn/entries # get the svn path of that specific corrupted file’s parent dir
url=”svn+ssh://xris@teacup/svnpath/lib/objects”
- cd /tmp # go somewhere we can play
- svn co svn+ssh://xris@teacup/svnpath/lib/objects . # check out a fresh copy of that dir
- cd - ; cd .. # go back to lib/objects, then up a dir
- mv objects /tmp/objects.orig # move the updated files to /tmp/
- mv /tmp/objects objects # move the fresh svn repos into your work dir
- svn update # just to be sure it works
- cp /tmp/objects.orig/blah.ext objects/ # move your updated blah.ext file back into your work dir
now look. you can’t just copy and paste the above, you know. i’m telling you how i fixed it for me, because the other instructions linked above yakked on about a representations file that i just plain don’t have …. so rather than fixing the MD5 entries in the DB, i just forced SVN to give me a fresh copy of the MD5 files for the lot.
i hope this helps. huzzah for the giant google brain!
Pingback by Developer Journal / Fix “svn: Checksum mismatch…” problem
— June 29, 2007 @ 12:35 am
Comments
amazingly, tests show it takes only 2 months after writing a blog entry on something technical before you face the same problem and google for the same answer
luckily, the second time around you may find your own notes on the problem, cheerily blogged for all to read
and save yourself an hour or two of grief trying to mess around with foolish db_dump / db_load fixes which just plain don’t work … when you had the notes all along
once i cursed the blogosphere. today i sing its praises.
ps. i’m using FSFS now, and all the corrupted checksum google results seem to relate to BDB repositories. so … don’t FSFS repos get corrupted?
Huzzah for the giant google brain, indeed. And double huzzah for it having helped me to find your post on the matter.
I’ve been fighting random corruption of an SVN repository, and had tried that same useless BDB trick with the “representations” voodoo, only because I’m not an SVN savant. Your method not only works in theory, it worked in practice, and made sense, to boot.
Thanks much for posting it.
I discovered an alternate solution to the checksum mismatch problem.
If we say the problem is in _templates.php, then you need to edit the ‘entries’ file in the .svn folder of that file.
This file could look like this:
.
.
^L
_templates.php
file
2007-08-22T12:26:44.000000Z
5e1bdc7a206840b14c984e95c9c95c39
2007-08-21T22:28:44.968799Z
410
hans
^L
gamingzone.php
.
.
From ‘entries’ you need to delete from the line _templates.php down to the line before gamingzone.php. Save, rename _templates.php and do svn update, and everything should be fine again.
Hope this helps someone.
Nothing for 3 months, then Sharken and I find your tip within 5 hours :)
Worked fine for me too, btw. Thanks a lot
Excellent work-around!
Thanks, that quick and dirty woarkaround saved me a lot of time ;-)
Thanks for the explanation, which shed some light on how svn manages its working copy. My problem seemed to stem from a bogus file under .svn/text-base, which didn’t match the file actually on the server.
- server file (…/x.java): OK
- orig copy from server (.svn/text-base/x.java.svn-base): BOGUS (not same as server)
- checksum (in .svn/entries): matches server, but not server copy
If I can make the bogus copy match what’s on the server, then it will also match the checksum, and everyone will be happy.
What I did (i’ll call the working dir with the corrupt file “orig-dir”:
1. Fresh checkout of svn dir matching orig-dir into /tmp/blah
2. Copy /tmp/blah/.svn/text-base/x.java.svn-base into orig-dir/.svn/text-base
3. Check in successfully
I wish svn would let you refresh a given file from the server…maybe there’s a command and I just haven’t found it or my svn is too old.
Thank you, man!
You’ve saved me a day ;)
Oh comeon people! Your fixes are way too overcomplicated.
Here’s the process for fixing file blah.txt:
1. Mark .svn/entries as readable, and open in a text editor.
2. Find section for blah.txt, and paste in the correct checksum, save the file, then commit.
3. Profit!
Excellent solution. While doing this I found an even simpler way:
2. first i checked in all the files that didn’t complain
3. move the directory that gives the problem to your temp directory
4. in the parent directory run svn update objects
5. copy the file that gave the problem back to the newly created objects directory
6. and commit your changes.
Hope this helps.
Marco.
Just run ’svn cleanup’.
perhaps a later version of SVN does handle this in cleanup? but i’m pretty sure i tried that the last time i hit this.
i also suspect that if cleanup did do this, this page wouldn’t get read / commented on half as often ;)
Thanks man for your solution. That error message was very annoying.
many, many thanks. for the record, ’svn cleanup’ does *not* fix this.
Hi!
Just rename the file with the checksum mismatch, one second later rename it back to its old file name. Then do a “commit”. Et voilà :)
That worked for me!
Cheers
Worked like a charm.
Thank you