Repair SVN Checksum

I'm using subclipse in Flex Builder 3, and recently received this error when trying to commit:

svn: Checksum mismatch for '/Users/redacted/Documents/Flex Builder 3/path/to/my/file.mxml'; expected: 'f8cb275de72776657406154dd3c10348', actual: 'null'

I worked around it by:

1. Committing all the other changed files, omitting the troublesome one.
2. Copying the contents of the trouble file to a TextMate window
3. Deleting my project in FlexBuilder/Eclipse
4. Checking my project out fresh from SVN
5. Copying the text of the trouble file back in from the TextMate Window
6. Committing the changes.

It worked, but I can't help but think there's a better way. What's actaully happening to cause the svn:checksum error, and what's the best fix.

Maybe more important -- is this a symptom of a greater problem?

The file in the .svn directory that keeps track of what you have checked out, when, what revision, and from where, has gotten corrupted somehow, for that particular file.

This is no more dangerous or critical than the normal odd file problem, and can be because of various problems, like a subversion program dying mid-change, power-disruption, etc.

Unless it happens more I wouldn't make much out of it.

It can be fixed by doing what you did, make a copy of your work-files, check out a fresh copy, and add the modified files back in.

Note that this might cause problems if you have a busy project where you would normally have to merge in changes.

For instance, you and a collegue both check out a fresh copy, and start working on the same file. At some point, your collegue checks in his modifications. When you attempt to do the same, you get the checksum problem you have. If you now make copies of your changed files, do a fresh checkout, then subversion will lose track of how your changes should be merged back in.

If you didn't get the problem in this case, when you got around to checkin in your modifications, you would need to update your working copy first, and possibly handle a conflict with your file.

However, if you do a fresh checkout, complete with your collegues changes, it now looks like you removed his changes and substituted with your own. No conflicts, and no indications from subversion that something is amiss.

There's also a simpler cause for this than just bugs, or disk corruption etc. I think it the most likely cause for this to happen is when someone writes a recursive text replacement on the working copy, without excluding .svn files.
This means the pristine copies of the files (basically the BASE version of the files, that's stored inside the .svn administrative area) get modified, and that invalidates the MD5 sum.

@Andrew Hedges: that also explains why your solution fixes this.

SVN keeps pristine copies of all the files you checkout buried in the .svn directories. This is called the text-base. This allows for speedy diffs and reverts. During various operations, SVN will do checksums on these text-base files to catch file corruption issues.

In general, an SVN checksum mismatch means a file that shouldn't have been altered was changed somehow. What does that mean?

1. Disk corruption (bad HDD or IDE cable)
2. Bad RAM
3. Bad network link
4. Some kind of background process altered a file behind your back (malware)

All of these are bad.

HOWEVER, I think your problem is different. Look at the error message. Note that it expected some MD5 hashes, but instead got back 'null'. If this were a simple file corruption issue, I would expect that you would have two different MD5 hashes for the expected/got. The fact that you have a 'null' implies that something else is wrong.

I have two theories:

1. Bug in SVN.
2. Something had an exclusive lock on the file, and the MD5 couldn't happen.

In the case of #1, try upgrading to the latest SVN version. Maybe also post this on the svn-devel mailing list (http://svn.haxx.se), so the developers can see it.

In the case of #2, check to see if anything has the file locked. You can download a copy of Process Explorer to check. Note that you probably want to see who has a lock on the text-base file, not the actual file you were trying to commit.

Just today, I managed to recover from this error by checking out a copy of the corrupted directory to /tmp and replacing the files in .svn/text-base with the just co'ed ones. I wrote up the procedure in some detail here on my blog. I'd be interested to hear from more experienced SVN users what are the advantages and disadvantages of each approach.

I occasionally get similar things, usually with files that nobody has been near in weeks. Generally, if you know you haven't been working in the directory in question, you can just delete the directory with the problem and run

svn update

to recreate it.

If you have live changes in the directory then as lassevk and you yourself suggested, a more careful approach is required.

Generally speaking I would say it's a good idea not to leave edited files uncommitted, and keep the working copy tidy - don't add a whole bunch of extra files into the working copy that you aren't going to use. Commit regularly, and then if the working copy goes tits up, you can just delete the whole thing and start over without worrying about what you might or might not be losing, and without the pain of trying to figure out what files to save.