Subclipse complains "Path is not a working copy" after moving workspace

Question

I recently moved my Eclipse workspace directory and now Subclipse complains every time I open a file, dumping to the console something like:

Path is not a working copy directory

svn: '[original (pre-move) directory path]' is not a working copy

No such file or directory

This also happens when I explicitly try to view the history of a file. This persists across SVN cleanups, closing and re-opening Eclipse, etc.

Update, checkin, checkout and so on all seem to work fine, and Tortoise doesn't complain at all, so clearly it's not the SVN metadata that's screwed up, it's some Subclipse-specific metadata. Can anyone tell me how to blow this broken metadata away?

---

Edited to add: "Team > Disconnect" followed by "Team > Share" doesn't solve the problem.

---

Edited again to add: I've grepped through the whole .metadata directory and one of the project directories for a unique element of the old path and can't find it anywhere except in .metadata/.log (the error message itself) and some old Findbugs warnings. Very nice.

Answer 1

Hard to say without further information.

Did you move the whole workspace or just the content?

Also, you can try creating new workspace from scratch and check out the whole project again.

Alternatively, you may try deleting the .metadata directory and relink the project again using File -> import -> existing project into workspace and then relink the SVN data through Team -> Share projects (with an 's'), or maybe just do this last bit after first disconnecting the project from SVN.

Answer 2

Sometime ago I had a similar issue. Seems that Subclipse (or Eclipse) stores the absolute path of your working copies. The cleanest solution is to export again your repository to the new path.

If you have non-committed code, then you can copy it on top of the clean export (without the .svn folder)

Answer 3

Edited to add: Nope, spoke too soon. This doesn't fix it. Some files just seem not to exhibit the problem.

---

The following seems to solve the problem:

1. Team > Disconnect.
2. Quit Eclipse.
3. Blow away .metadata/.plugins/org.tigris.subversion.subclipse.*.
4. Restart Eclipse.
5. Team > Share.

Not sure how the old path was actually being stored in the plugin prefs, but it must have been in there somehwere. It's kind of pathetic of Subclipse to store absolute paths, but apparently it is.

There's a bug filed on this, or at least on the same error message. No context. Fifty cents says it gets rejected.

Answer 4

I was having the same error message using subclipse with javahl on a project that is out of the workspace directory. Changing to svnKit has resolved my problem.

Answer 5

I have the same problem

I had a new project, added it to SVN. Then everything works as normal, until I try and refactor-rename any java file, I get:

move D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/Skbean.java D:/dev/sk_ws/ge-parent/ge-core/src/main/java/com/skillkash/ge/beans/SkBean.java Path is not a working copy directory svn: Path 'D:\dev\sk_ws\ge-parent\ge-core\src\main\java\com\skillkash\ge\beans\SkBean.java' is not a directory

Now the SVN URL is: svn://qnap/share/MD0_DATA/svn/sk/ge-core/trunk and the repository root is: svn://qnap/share/MD0_DATA/svn/sk

Obviously just sharing the project then trying to move a file using subclipe does not work - it must be a bug. I have to do all my refactoring outside eclipse, and hand edit all the files which are affected.

Answer 6

You need to delete the .syncinfo files. See this article: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=868799

Answer 7

I'm sure there are many causes with different solutions, but the one that worked for me was at http://bit.ly/9qQcPy at Dan Wilson's blog. Simply remove the offending folders from the workspace (probably saving them if they have new content), update (letting Subversion recreate the folders), then move the contents back into the fresh folders in your workspace.