Update #2: After a few weeks of testing this issue out, I’ve narrowed down the issue to the following scenario that causes this to happen:
- Invoke an SVN operation that pops up a dialog (like a commit)
- Hit the action button (e.g. “Commit”)
- ISSUE: Sometimes the dialog will hang for up to 8 seconds, looking like it’s either frozen or hasn’t gotten the action (mis-click), but it HAS. If you click the action button again (e.g. “Commit”) this time the dialog will dismiss but two simultaneous actions of the same time will fire and corrupt the local copy of the repo.
- WORKAROUND: Be sure you are clicking the action button, then regardless of if the dialog dismisses or not, just wait. Don’t click anything else again. 9 times out of 10, after 3-5 secs, the dialog will disappear and the action will run correctly and you have avoided a world of hurt.
I already blogged about running into problems with IntelliJ 9′s SVN operations once before, and here I am again, unable to check a goddamn thing into my repository because it’s done it again “Checksum mismatch while updating…”
Previous to this error I tried to commit 10 changed files that had a refactored common method in them (they had JUST been checked in 1 hour before). The commit operation failed for no reason explaining that a merge operation had failed… there should have been nothing to merge especially during a commit operation and now my workspace is hosed.
My previous solution of manually removing the files and loosing history won’t work because there are quite a few files I need to check in and I can’t keep loosing history like this just to get IntelliJ to work.
God in heaven am I frustrated right now. I’m going to look into falling back to Tortoise SVN for the time being just so I can keep working.
I can’t reiterate this enough – How can local changes to a file cause a commit operation to fail, this is the entire point of source control.
ARGH!
Update #1: An hour later with Tortoise SVN and I’ve gotten my working copy restored. This tip is the only one that worked for me. I read a few that talked about copying just the entries file or manually editing the .svn files — NONE of those worked for me. The only thing that worked was to take my broken dir, move it off somewhere, and drop-in the same dir from some other checkout that was working.
Once I confirmed that dir worked (SVN Update/Commit make sure no changes were showing) then dropping the changed source files only from my broken dir back onto the working one and committing those changes. Make sure you don’t re-copy the .svn folder.
Overall this strategy completely falls apart if you have a lot of changes to your workspace as you’d have to hand-copy/move each dir and this solution doesn’t scale at all.
I’ve used SVN for 2 years with Eclipse and the Subclipse plugin — never seen this problem — give me 1 month with IntelliJ 9.0.1 and I’ve seen it twice now.
I think for now to not even run the risk I’m going to manage source control using Tortoise SVN, which annoys me almost as much as the problem occurring in the first place since I’m loosing a lot of the value of an IDE with that.
ARGH x 2!
