subversion checksum mismatch - easy workaround
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!
Comments
Thanks! This truly is the simplest solution I've seen! =)
Great! That worked. Thanks!
By the By, finding the revision number and repository info is very very easy. "svn info" on the working directory will tell you all the info you need to know, except perhaps the login name. svn co -r {revision} {url} will check out the right revision as well.
While chasing after a checksum mismatch issue, I found this, and it confirms what I was suspecting, that it was that base-text's checksum that was incorrect as compared to the entries file. That checksum invalid message could be much more helpful. Though I do admit... What's an average user to do when the .svn directory gets out of date besides get a fresh copy and re-apply the modifications? Perhaps that's the solution the error message should suggest instead of just leaving it as "Checksum error"
There is a very large caveat that must be given here. No matter the method of getting your new working copy, if you want to commit your changes made to the original working file, and unless you are sure nobody modified the offending file in the meantime, you must do a diff between the new working copy and the file you modified and merge the two files by hand. If you simply overwrite the new working file with a file based on that older version, you will clobber any changes that were made since you first checked out the file to modify it. If you find the rev you were modifying, you could get a working directory at that rev, of course, and skirt this merge issue.
I must strenuously point out that the "Just delete that section out of the entries file" solution is likely to be "Not what you wanted. (tm)" Until you get a fresh copy from the repository, the file whose entry you removed from .svn/entries will no longer be updated by subversion because the client doesn't know it's part of the repository.
And thirdly, updating the entry with the (md5) checksum of the file currently in text-base is also likely to have unknown consequences. Unless the server does a double check, you could well end up with a commit of an identical file through this method. Unless the error was in calculating the checksum for the entries file, even an unchanged file will look like there were changes made to the file because the corrupt text-base copy will have a different checksum than the file in the working directory.
[...] are some scary ways out there to get around “checksum mismatch” in subversion but this one really made it simple and worked just fine. I figure a solution that fixes a potentially scary [...]
Worked like a charm.
Thank you
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
many, many thanks. for the record, 'svn cleanup' does *not* fix this.
Thanks man for your solution. That error message was very annoying.
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 ;)
Just run 'svn cleanup'.
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.
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!
Thank you, man!
You've saved me a day ;)
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.
Thanks, that quick and dirty woarkaround saved me a lot of time ;-)
Excellent work-around!
Nothing for 3 months, then Sharken and I find your tip within 5 hours :)
Worked fine for me too, btw. Thanks a lot
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.
[...] found a blog post “subversion checksum mismatch - easy workaround“, same problem, similar solution. Post a comment — Trackback URI RSS 2.0 feed for [...]
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.
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?
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.