SVN - Checksum mismatch while updating

When I try to update some files from Subversion, I get the error:

org.tigris.subversion.javahl.ClientException:
Checksum mismatch while updating 'D:\WWW\Project\\.svn\text-base\import.php.svn-base'; expected: '3f9fd4dd7d1a0304d8020f73300a3e07', actual: 'cd669dce5300d7035eccb543461a961e'

Why do I get this? How can I fix it?

142059 次浏览

The easiest way to fix it (if you don't have many changes) is to copy your changes to another directory, delete the directory where your project is checked out, and checkout the project again.

Then copy your changes back in (don't copy any .svn folders) and commit, and continue.

In case you are using SVN 1.7+ there is a workaround described here.

Just to recap:

  1. Go to the folder with the file causing problems
  2. Execute command svn update --set-depth empty (note: this will delete your files, so make a copy first!)
  3. Execute command svn update --set-depth infinity

I found an easier way to fix this issue. You cannot do this directly from eclipse. Steps:

  1. Navigate to the workspace folder structure in windows
  2. rename the folder
  3. refresh in eclipse
  4. Now the folder and files will be removed from project in eclipse and will appear under new renamed folder
  5. Now try "Synchronise with Respository" option.

This will restore text base folder in .svnfolder . Checksum mismatch while updating error will not appear further.

This happened to me using the Eclipse plug-in and synchronizing. The file causing the issue had no local changes (and in fact no remote changes since my last update). I chose "revert" for the file, with no other modifications to the files, and things returned to normal.

I had a the same error but for one file. In IntelliJ IDEA I was able to make a copy of the file, then go into the project and delete the file in question, then commit successfully. Then, I made a new file with the same name and copy the contents back into it. I guess you would lose the revision history but it does work.

To resolve this follow following steps:

  1. Open the entries file located in .svn directory where you are getting the error.
  2. Find the entry for the file giving error and replace the expected value with actual value in error.
  3. Now synchronize and try to update.

If it still does not work. Try these. Its just a workaround though:

  1. Delete the file from your system.
  2. Delete the entry of the file from entries file. (Starting from the name of the file till the special characters).
  3. Now Synchronize and update the file.

This will get latest version of file from repository and all conflicts will be resolved.

had a similiar issue on a server but the SVN directory was very large , didn't want to delete and resync so I just made a copy of the files locally and then deleted them. When update succeeded and added files back in.

try to delete the file and remove the file reference from file entries under the .svn directory

I had a simllar problem. Main provider was antivirus "FortiClient" (antivirus + VPN CLient). When I disabled it - all update/checkout was made correctly

I had a similar error and fixed as follows:

(My 'fix' is based on an assumption which may or may not be correct as I don't know that much about how subversion works internally, but it definitely worked for me)

I am assuming that .svn\text-base\import.php.svn-base is expected to match the latest commit.

When I checked the file I was having the error on , the base file did NOT match the latest commit in the repository.

I copied the text from the latest commit and saved that in the .svn folder, replacing the incorrect file (made a backup copy in case my assumptions were wrong). (file was marked read only, I cleared that flag, overwrote and set it back to read only)

I was then able to commit successfully.

If you have a colleague working with you:

1) ask him to rename the file causing problems and commit

2) you update (now you see the file with invalid checksum with different name)

3) rename it back to its original name

4) commit (and ask you colleague to update to get back the file name in its initial state)

This solved the problem for me.

I found very nice solution, that SOLVED my problem. The trick is to edit the svn DB (wc.db).

The solution is described on this page : http://www.exchangeconcept.com/2015/01/svn-e155037-previous-operation-has-not-finished-run-cleanup-if-it-was-interrupted/

If link is down, just look and follow this instructions: enter image description here

I used sqlite tool from http://sqlitebrowser.org/.

My solution was:

  1. Execute svn cleanup from file system
  2. Switch to another branch
  3. Solve conflicts
  4. Switch to the "problematic" branch
  5. Execute cleanup from Spring Tool Suite
  6. Execute Project Update

1.'update to reversion' check 'only this item' under the directory 2.update again check 'Fully recursive'

I'm using Tortoise SVN, after tring all solution in this page and not working,

I finally back up the problem file. and use Repo Browser delete the problem file in it, then update local folder so the file in local folder is deleted. Then copy back the backup file and Add > Commit, then I can update successfully.

The only disadvantage of this method is the history of this file will be removed.

Had the same issue, what worked for me is.

  1. Tried SVN checkout of the affected branch into a new directory
  2. Waited till the .svn folder get added in the new directory 3.Copied and replaced the old .svn directory from the affected branch with the new .svn directory
  3. SVN Clean up
  4. SVN Update

After following these steps I was not able to get the SVN checksum mismatch error and the Update was working as normal

I had a similar issue with svnkit-1.10.71. I compared the file I was getting from the server to the file I was uploading back to the server using NotePad++. There was an unexpected difference in the file. Even though I made sure to convert the bytes to UTF8 string, a character still ended up being encoded incorrectly. It was ö om RÖMPP. It got converted to something like RÖMPP. I change ö to o, and it fixed the problem. The file I am using should not have these special chars.