Fix Subversion “checksum mismatch” error by editing .svn/entries file

I can’t explain why this happened because in my several-year-long history with Subversion, I’ve never experienced this issue once. However, today, I fell into the (arguably) unfortunate circumstance of running into a most disturbing error from SVN. When trying to commit my changes, SVN barfed at me and complained of a “checksum mismatch”. It looked something like this:

Transmitting file data ..svn: Commit failed (details follow):
svn: Checksum mismatch for '/Users/maymay/Sites/path/to/subversion/working/copy/.svn/text-base/working-file.php.svn-base'; expected 'cde4d8fbd5c623da3a8b1a343aa7b3f4', actual: '270b2f20804a5fcdbd15eec5910f6e3f'

Of course, the path/to/subversion/working/copy bit was the path to my working copy file’s parent directory and the working-file.php was an actual file in my working directory.

I think what Subversion was trying to tell me is that its hashed copy of the working-file.php file and the copy I was asking it to commit weren’t the same. It would be nice if it would actually tell me why that happened, but it’s clearly more temperamental than that.

Anyway, to fix this issue (at least for now…?) I simply checked out a new working copy of this directory, examined the .svn/entries file from it and sure enough, found the actual checksums in there, just as Subversion reported expecting. I simply copied those expected checksums into the .svn/entries overwriting the old actual checksums and, voila, Subversion has been fooled. After that, I could commit my changes.

Step by step (because I’m sure someone, somewhere, somehow, will run into this again—if it’s not me that is!), this procedure looked like this:

  1. Copy the “expected” and “actual” checksums Subversion reports to you to a new text file so you can refer to them later. Note which one is the expected and which is the actual checksum.
  2. Go to where the problem is (that is, cd path/to/broken-files-parent-dir/.svn)
  3. Open the entries for editing (for example, vim entries)
  4. Search the file for the actual checksum.
  5. Replace it with the expected checksum. Be careful not to change any other part of the file.
  6. Save the file.
  7. Try to svn commit again.
  8. Lather, rinse, and repeat for any other files Subversion barfs at you about.

I’m sure this is not an elegant or even the recommended solution to this problem. The truth is I never bothered to look up what the recommended solution is, because it seems to me that any code repository that can’t guarantee what I get out of it is the same as what I put into it isn’t a versioning system I really want to trust the “recommended” solution of, anyway.

Also known as: this is another reason why I like git better now.


  1. Tobias Janz says:

    i had the checksum missmatching problem to, but in my .svn/entries file was the expected md5 and not the actual, did you meen to replace the expected with the actual? Did not work to.
    My broken file was in directory Projects and was named “build.xml”. I switched to Projects/.svn and opened “entries” with textmate.

  2. Meitar says:

    i had the checksum missmatching problem to, but in my .svn/entries file was the expected md5 and not the actual, did you meen to replace the expected with the actual?

    Um…not sure. I’m pretty sure I get it right in my post, but I can’t verify this since I don’t know how to replicate the issue. I imagine you should just need to replace the one with the other. Of course, that’s assuming this is the source of your error, which I can’t be certain about either.

    You might do well to follow the advice on some other, similar blog fosts that I discovered with a Google search on “subversion checksum mismatch”. See, for instance:

    Moving objects around.

    Using db_dump, though I’m not sure what that is.

    Another .svn/entries fix.

  3. Anurag says:

    Same experience, however changing the entries did not work.

    I found actually a more straight forward solution, which in retrospect may be a bit silly.

    I simply made a copy of all the files which have been affected (actually only the files that have been sitting in the root of the project) and then deleted all those files from the project. I committed the delete (no problem there) and then simply re-imported the files and did another commit. Also this caused no further issue, all the revision numbers have been updated accordingly and it all looks good.

    I am sure too, that this is not an elegant or recommended solution :)

  4. Meitar says:

    Hi Anurag. Yeah, the thought of needing to delete and then re-add the files from revision control does seem silly to me. Glad to hear that worked for you, though. Also, thanks for sharing that tip with me.

  5. Venura Athukorala says:

    Copy the files to somewhere else.
    remove the directory.
    svn update.
    then recopy the backup over the checked-out version without the .svn files
    editing the checksum is not a safe solution, believe me

  6. RJ says:

    If the files with mismatched checksums are not modified, just remove the local copy and update to restore them and recalculate the checksums. If modified, move them elsewhere instead of deleting, then copy them back in place of the fresh copies after updating. No need to touch the repository itself.

  7. me says:

    running svn, version 1.6.12 (r955767) here

    checksum not found in ‘entries’

    [filename] and .svn/text-base/[filename]
    were of different content

    copying the incriminated file to .svn/text-base/
    chmod -w svn/text-base/[filename]

  8. Oleg Efrem says:

    I had same problem. Just fixed it.
    I navigated to .svn\text-base dir of problem file’s parente directory and found out that there’s a copy of the file i was trying to check in changes for. I opened that file in Notepad++ and replaced it’s content with content of the file to be commit-ed and i was able to commit afterwards. But just in case, make a backup copy of the .svn\text-base file.
    Hope it helps someone.

Comments are closed.