Subversion (subclipse) corruption in Eclipse

I use subclipse to manage my subversion interactions in eclipse. I also use TortoiseSVN for pulling clean source code trees that are separate from my development workspace to produce releases. Normally, "never the two shall meet" is my policy. Eclipse/subclipse manage projects in my workspace directory and Tortoise handles everything else. I just found out what happens if you let them cross paths.

I had a project in eclipse that seemed to have corrupted it's svn meta-data. The Synchronize view insisted that I had added some files when I hadn't. After restarting eclipse, the Synchronize view insisted that the whole source tree had changed. Trying to narrow the problem, I quit eclipse, opened Windows Explorer, and told Tortoise to check for updates and local mods in the project. Tortoise turned up a big nothing; it didn't think there were any changes (which was correct). So I went back into Eclipse to see if I could find a pattern to it's madness. (I know, I know - "This is eclipse, " you say, "to which madness are you referring?"). Trying to synchronize the project again resulted in this helpful messages in the SVN console:

update C:/Dev/workspace/myproject -r HEAD --force svn:
'C:\Dev\workspace\myproject' is not a working copy
svn: Cannot read from 'C:\Dev\workspace\myproject\.svn\format': C:\Dev\workspace\myproject\.svn\format (The system cannot find the file specified)

For any who don't know the inner workings of subversion (like me), under subversion 1.4 and below, the format file contains the version of the meta-data. 9 for version 1.4, 8 for 1.2 (I think), etc. With subversion 1.6, that file is removed and the meta-data version is written in the top line of the entries file.

Lesson #1: The subversion version used by eclipse may be different from the version used by your standalone subversion client.

I use Tortoise 1.6.2. This uses subversion client 1.6 libraries. My subclipse plugin is from the 1.4.x branch. As the Tortoise FAQ will tell you, subversion versions 1.4 and above will automatically upgrade the working copy format of your meta-data. So the message was correct - the format file wasn't there. I just didn't yet understand what had happened to cause that. I thought I was still dealing with the same unknown error that I started with when, in fact, I had managed to create a whole other problem to deal with.

Somehow (and the steps get blurry here) I got Eclipse to give me a better error:

Problems reported while synchronizing SVNStatusSubscriber. 0 of 1 resources were synchronized. An error occurred synchronizing /myproject: Error getting status for resource P/myproject org.tigris.subversion.javahl.ClientException: Unsupported working copy format

svn: This client is too old to work with working copy 'C:\Dev\workspace\myproject'. You need to get a newer Subversion client, or to downgrade this working copy.
See http://subversion.tigris.org/faq.html#working-copy-format-change
for details.

Ah-hah! So I at least knew what had caused the latest behavior. Upgrading my subclipse plugin to the 1.6.x branch got me back to my original problem. Nice to be back in known territory.

I knew that the subversion meta-data that I could see (stuff in the .svn directories) was okay since Tortoise functioned. So eclipse must keep some other meta-data about the synchronization state of a project. Time to delve into the dark world of the workspace .metadata directory. I searched through that directory for anything with the name of my project. After eliminating a few hundred hits in .markers and .history files and whatnot, I found a likely sounding culprit - .syncinfo. Sure enough, armed with that file name, I searched the web for references to my problem and turned up an archive of the subclipse-users mail list with exactly what I needed.

Lesson #2: If the subversion integration in Eclipse ever goes haywire for a project, delete this file:
[workspace dir]\.metadata\.plugins\org.eclipse.core.resources\.projects\[project name]\.syncinfo

Problem solved. Now I just have to get maven, eclipse, and groovy playing nicely with each other...