subversion checksum mismatch - easy workaround

Thanks. Saved my ass :)

If you don't have any pending changes in the directory, nuking and paving is a bit easier:

Assume that ~/trunk/a/b/file.txt is the file twisting svn's knickers. Run

svn info ~/trunk/a/b

to get the svn URL (say it's "http://svn/repo/trunk/a/b"), then

cd ~/trunk/a
rm -rf /b
svn co http://svn/repo/trunk/a/b

and all should be well again.

Team-->Cleanup
Team-->Update

worked in my case, bye!

Hi, thanks for taking the time to post this solution. It's very frustrating when stuff you use to work stops working... yoursolution was easily understood, not too intrusive to SVN and most importantly, solved the problem! Thanks again.

Thanks for the solution!

I encountered this today and the problem turned out to be keyword expansion:

$ diff -u clean/.svn/text-base/file.php.svn-base corrupted/.svn/text-base/file.php.svn-base
--- clean/.svn/text-base/file.php.svn-base 2009-02-27 13:50:13.000000000 -0600
+++ corrupted/.svn/text-base/file.php.svn-base 2009-01-30 21:34:22.000000000 -0600
@@ -1,6 +1,6 @@
 <?php
-# $Id$
-# $HeadURL$
+# $Id: file.php 661 2009-01-31 03:07:45Z user $
+# $HeadURL: svn://svn/project/trunk/lib/php/file.php $

Just collapse the keywords in corrupted/.svn/text-base/file.php.svn-base and everything will be back to normal. (Dunno how they got expanded in the first place though...)

HTH.

my solution with smartsvn

do with the parent dictionary of the problem file:

context menu on the directory: update ...
go to tab: basic
update to: HEAD
go to tab: advanced
option: [x] Rebuild SVN admin area completely

NOTE:
this is disabled (grey out) if you try this with the file itself - do it with the parent directory

used tool:
SmartSVN Foundation version (free)

see also:
SmartSVN documentation
http://www.syntevo.com/smartsvn/documentation.html?page=commands.update

Thanks for the info and the time taken for sharing it with us -> worked for me!
Don't want to appear pedantic, but noticed in example that step 6. checkout of objects dumps the contents in /tmp rather than the directory. Should maybe be:

6. # svn co svn+ssh://xris@teacup/svnpath/lib/objects /tmp/objects # check out a fresh copy of that dir

You'd save on steps 5. and 7.
Cheers,
Johnno

It took me a bit to figure out how your problem related to mine (ie. directory and project structure), but once I figured that out this worked like a charm. it was a breeze.

I just experienced this problem, and came up with what appears to me to be a much simpler solution. In particular: svn is pointing out to you that the file in your text-base directory is corrupted. The solution? Fix the offending file. That is: download a fresh copy of the repository on the side **for the version that your corrupted checkout claims it has**, then use the base file from that checkout to replace the corrupted base file.

In my case, I couldn't update from version 2180 to 2186 on a particular file. So, in a side directory:

svn co -r 2180 svn+ssh://blah-blah-blah/research/tax-forms%20paper /tmp/tfp
Then use the file from /tmp/tfp/.svn/text-base/foo.tex.svn-base to replace my-corrupted-checkout/.svn/text-base/foo.tex.svn-base

Then update as normal.

This eliminates the possibility of missing some changes in the swap described by this article, and handles the local changes to the offending file in the way that svn is supposed to.

Granted, both my solution and the one described by this article are vastly less scary than the totally horrific idea of editing the MD5 checksum log directly.

John Clements

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.