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:
- 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.
- Go to where the problem is (that is,
- Open the
entriesfor editing (for example,
- Search the file for the actual checksum.
- Replace it with the expected checksum. Be careful not to change any other part of the file.
- Save the file.
- Try to
- 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.