Wednesday, February 1, 2012

Subversion 1.7, file & folders manipulation and Checksum mismatch error

Issue
In Subversion 1.6, we have got accustomed to manipulating working copy sub-directories as we wish, having a way to easily restore broken folder working copy. We performed it by deleting the problem folder and getting it fresh again by running svn update command.

After upgrading to 1.7, during such manipulation, we often encounter error like this:

svn: E155017: Checksum mismatch for 'D:\project\Aggregation\Service.cs':
   expected:  c446841fc97da2f6399ac77e334f2be2
   recorded:  0a896afb3a1923f11ef3794e2aae428b

Any attempt to remove folder and get it updated again does not fix the problem. Checksum mismatch appears on commit, revert or other operations with the working copy.

Cause
Subverion 1.6 stored the working copy cached repository information, like base revision files and their hashes, in every directory. Owing to this, a lot of folders .svn were located in the working copy, and we had to deal with them if we tried to copy or move parts of our working copy without exporting them. But this allowed such manipulation as I described above.

Subverion 1.7 stores this stuff in the working copy root only (for externals, it stores it in the root of an external working copy too).


Solution (workaround)
Instead of just deleting folder and then updating it, you perform a hack with the depth of the problem folder, setting it first to empty, then to infinity:


D:\project\Aggregation\> svn update --set-depth empty
D         Service.cs
Updated to revision 156.


D:\project\Aggregation\> svn update --set-depth infinity
A         Service.cs
Updated to revision 156.


It will remove the cached information about the problem directory from the working copy "cash-hash", and then restore it again with the actual information from the repository. So the error should disappear.

Related links
  • http://glob.bushi.net.nz/glob/2007/02/14/subversion-checksum-mismatch-easy-workaround/

This link is about Checksum mismatch error too, but it seems to solve another problem, and not related to 1.6-1.7 upgrade issues.

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)
  1. 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'

10 comments:

  1. Thanks .. The commands

    1. svn update --set-depth empty
    and
    2. svn update --set-depth infinity

    solved my problem . Thanks MouDrick

    ReplyDelete
    Replies
    1. I am happy to have helped you. :)

      Delete
    2. and 2 years later it helped me out ....
      Got the tip about this solution from freebsd-stable@freebsd.org mail list today, and it worked like a charm.

      All the best, and lots of hugs :-)
      Hasse Hansson
      SysAdmin Thorshammare.org

      Delete
  2. This didn't work for me, unfortunately. I was hoping it would. I hate creating new workspaces because of horked svn configs.

    svn: E155036: Working copy 'C:\workspaces\...\reports' is too old (format 10, created by Subversion 1.6)

    ReplyDelete
    Replies
    1. try using [svn upgrade] first

      Anyway, the latest svn 1.7 should suggest this operation for you

      Delete
  3. Thanks a lot, this solved my problem too. We'll try to get everyone to upgrade to 1.7 :).

    ReplyDelete
  4. On executing the above svn update command, this is wat I get - 'svn' is not recognized as an internal or external command,
    operable program or batch file.

    ReplyDelete
    Replies
    1. Just install svn and put ots bin foldet to PATH environment variable

      Delete
  5. Thanks a lot. It fixed the issue

    ReplyDelete