Forums / Subversion Help / svn checksum mismatch

Subscribe to svn checksum mismatch 29 post(s)


It’s driving me insane! :)

I’ve been trying to solve this problem for hours and I just can’t seem to figure it out. I even have removed all files from the repository and added everything back, then checked out a completely fresh copy on the server, and still getting this error.

This is what I’m getting when I try to do an svn up on my webserver:

svn: Checksum mismatch for ‘bom-ad-contest/form.php’; expected: ‘83030130d6ac92a9575339aecf39e409’, actual: ‘bfeaa8fda2bf17ba41cd39cca7b8eaed’

For what it’s worth, this is just an example of the error message I’m getting, it’s not just limited to the file “form.php”, I’ve seen the error on other files as well.

Adding and doing fresh svn co of the repository is working fine. It’s when you then make a change and commit it to the repos, then try and do an update somewhere else that it spits the error. My workflow is, I’ve got a checkout on my laptop, and and a checkout on the webserver. I make changes locally and ssh onto the server to do svn up there.

I’ve googled the hell out of this and none of the suggestions I’m find out there are working. Has anyone else run into this problem? And what did you do to fix it?

Joshua Frappier

As this is an issue specific to your repository, it would be helpful if you could email us your account details. Once we have received your information we can investigate this issue further for you.


Tim Berston

We are also seeing the same issue starting at about the same time as the original poster. So far any machines updating using tortoise appear to work ok, but those using svn command line appear to have the issue (not conclusive yet).

Were you able to resolve the issue for buzzyapyear? Is this affecting many repositories?


I can also confirm that the issue is happening for us as well on our Linux web server, and appears to be new for us in this past week. Developers running Eclipse are not affected.

buzzyapyear, one temporary workaround is to remove the entire directory containing the mismatch file and updating again, e.g. rm -r bom-ad-contest && svn update bom-ad-contest. Of course this is only a workaround.


we are getting the same problem with our account trying to svn up. This is happening on multiple servers

Bruno De Bondt

Same problem here: ‘svn checksum mismatch’ error on svn up. People here using svn 1.6.5 seem to have no problem though, lower svn versions all have the problem.

David C.

If you are experiencing problems with the “checksum mismatch” please email support with your account subdomain, the name of the affected repository, and any error messages you may be receiving.

Please also make sure you are using the most current version of your Subversion client.


Same problem here. Updating to the 1.6.6 client version fixed the issue, but I’d really like to have the three hours of my life back that I spent trying to figure out what happened.

Unfuddle admins: maybe a courtesy notice next time a breaking change is made would be a good idea.

Joshua Frappier

UPDATE: We have been working personally with many of you and can now confirm that upgrading to Subversion 1.6.6 on the client does fix the issue.

Typically, we do notify of changes that will affect our customers. Unfortunately, in this particular case, we still have ABSOLUTELY no idea why this problem began occurring when it did. While we did migrate some accounts between servers last week, there was no change to system software (or anything else) that would logically explain how this began to happen.

We are still investigating the source of the issue, but for now, the good news is that a simple client upgrade will get you up and running again.

Thanks all for your patience on this one.


i’ve spent the last couple hours trying to upgrade the svn client on my server, with no success… any other ideas, preferably simpler?


For folks running Ubuntu, updated packages are available, see this post on

Jo Wouters

I do not consider forcing your customers to upgrade their Subversion client to be a good solution.

A lot of us do not control the production servers.
We have company policies regarding upgrades of our software, which can’t be bypassed. And upgrading software on our production servers involves extra manpower and extra testing.

I’m confident that your team will work untill they manage to find an acceptable solution.


Also, we have found that older versions of linux don’t have upgrade options available.

Bruno De Bondt

We tried upgrading one of our dev machines: upgraded to v1.6.5 of the svn client, and did a clean
checkout of one of the repositories where we are experiencing problems.

We are now seeing this error on that dev machine:

> > svn: Can’t make directory ‘/mnt/ebs/unfuddle_shared/svn//dav/activities.d’: Permission denied

UPDATE: We’re experiencing this problem on 3 different machines.

Any info on the source of the problem?

Doug Avery

Getting the same error for the past two days; I’m working with the Cornerstone SVN client (which is using SVN 1.6.6). Error is:

Description : Checksum mismatch for ‘(filename)’; expected: ‘177298751d5b7536799a3f480fb75da0’, actual: ‘9eb580dfe4247537f7e05c7359fd242e’
Suggestion : The operation could not be completed.

Jo Wouters

It’s rather shocking to notice that the last update on this issue by the Unfuddle administrators is from 17 hours ago.
This SVN issue has been blocking whole teams from deploying their projects on production servers for 2 days now.

@Joshua & @David: could you please keep us up to date on an hourly basis on what’s going on, what you have done to understand this problem and what you are going to do to resolve it ?

Please also update your maintenance page; so your customers can easily find a status update.

Doug Avery

Like Buzz was saying, the error seems to drift from file to file, my only fix so far is to delete the entire working copy before each update and commit. The errors seem to begin after another user makes a change, but I can’t confirm this yet.

Bryan S

@Doug: I’m confirming that – even after deleting the entire working copy and starting over, if another change is made in the repo from a different location and checked in – ‘svn up’ on this copy returns the ‘Checksum Mismatch’ error. Something must have happened to unfuddle’s subversion server that is causing this. Upgrading to the bleeding edge subversion client is difficult or impossible for most users – and doesn’t fix the problem.

Joshua Frappier

UPDATE: We are no closer to understanding the source of the problem. However, we have received overwhelming confirmation that upgrading to the latest version of Subversion resolves the problem.

Unfortunately, while we are still actively trying to determine the cause, the reality is that upgrading to 1.6.x may end up being the only solution we can offer. In the case that we have any new information regarding the problem, we will be sure to post it here.

dr monkey

I started seeing this problem yesterday too, a huge pain in the ass when checking out a repo takes more than 15 minutes.

Any tips on upgrading on a RHEL system? Yum is happy with 1.4.2 as the latest…

dr monkey

CollabNet has a 1.6.6 binary for RHEL5 that worked for me


Is there any more info on this problem?

Upgrading my deployment servers and my development machines is not an option at this point. Doing a complete rebuild on the deployment side isn’t in the cards today either.

There must be some kind of script someplace which can zap/reset/whatever the checksums on the deployment side so updates work again.

If the top-most .svn is right, should an update then reload all the .svn’s below it?

Jo Wouters

@Joshua have you considered calling collabnet (or some other SVN experts) in order to have a look ?
These guys are experts; and since subversion is an essential part of your commercial offering, it might be worth the costs (and it might save you some customers that are losing confidence in Unfuddle right now)

For what it’s worth: the hints I got:

  • a load balancer or proxy does something weird with the traffic
  • apache configuration uses modules (mod_deflate?) that are not in sync with svn
Joshua Frappier

UPDATE: We have just made some changes to our configuration in the past hour that we believe may address the problem. If you do an svn update on your repositories using 1.4 then things should be working again.

Please feel free to share your results in this thread.


Looks like you guys fixed it. Well done!

Bruno De Bondt

Fix seems to work for us as well. Thanks!


We have experienced this issue 3 times in the last month while using svn client version 1.6.6.

Jaret Frappier


This is not likely related to the above posts, it is more likely due to corruption of your working copy. Does making a fresh checkout of the repo resolve the issue? If not, please do not hesitate contacting us at Support with the URL of your repository, and we will be happy to assist you.



We are experiencing the same issue with checksum errors when we commit from two different locations with 1.4.X clients to a 1.6 server installed on an openSuse.
Could you detail which configuration changes you brought to your server to make it compatible with those commits from clients 1.4.X.