subclipse - Repair SVN Checksum

Question

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?

Answer 1

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.