I created a Spring project with SpringToolSuite from a SVN project. It worked successfully. Now I deleted the project without deleting the content on disk. I want to create a project from the folder of the previously deleted project but I could not create it : there is a message stating that a project of the same name already exists in the workspace. So how to fix that ?
I do not know about SPringToolSuite, I work with Visual Studio. There, if you remove your project from the solution happens the same, it kept on the hard drive just disappears from the solution explorer.
If you want to reopen it, you can just open the project file or add it back to your solution.
If you want to create another project with the same name at the same location, you have to manually delete or move the folder of your old excluded project.
Depending on your use case, you can try to do something similar.
I hope this helps.
I zipped my whole workspace once in a while and want to reanimate it now. Some stupid sync crashed my current state. What I tried is to unzip it and then changed the workspace of eclipse to the newly generated folder.
The problem now, my Eclipse is blank containing now projects at all, the Package Explorer is empty, even after pressing F5? Any suggestions?
Do I have to use same Eclipse Version, which I used when producing the zips? Does a Computer change from 32 to 64 Bit or visaversa make a difference.
Thanks in advance!
I would delete your .metadata folder and re-import the projects manually. The metadata will be automatically regenerated.
Did your zip file contain the hidden .metadata folder? (This is where Eclipse stores preferences and launch options.) If not, that may be reason why you don't see your projects as before.
You can try to import existing projects. Then you should at least see the projects again.
I run eclipse on Ubuntu 11.10. I originally created a project in folder foo. I subsequently deleted that project to re-organise folders and I now want to create a new project in folder foo/bar but Eclipse won't let me because it says the the new directory is a sub-directory of an existing project.
How can I force Eclipse to forget about the original project so that I can create the new one?
In general, the deleting the project from the "/.metadata/.plugins/org.eclipse.core.resources/.projects" should work, but if you're using 'working sets', you might have the problem I had once, which is basically have a 'ghost' project in your workspace that you can't delete because it says "this project doesn't exist anymore".
If this is your problem, try to delete an entry for your 'ghost project' in the file:
"/.metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml" (on MacOS).
Delete the project from /.metadata/.plugins/org.eclipse.core.resources/.projects and not the whole .metadata folder will save all other projects and config.
I have also encountered this problem, except it's been in Windows. I didn't want to completely remove the .metadata folder and none of the other solutions fixed it.
I managed to fix it by removing the file workspace\.metadata\.plugins\org.eclipse.core.resources\.safetable\org.eclipse.core.resources while Eclipse was closed. The file gets saved when closing Eclipse so I guess it is cached while Eclipse is open.
Go to your workspace folder using some file manager (you can find your workspace location, be clicking File -> Swich Workspace...) and delete your foo folder, or simple remove its contents (.project file being most important). Then you should be able to create your new project.
I finally managed to fix it by deleting the workspace/.metadata directory. This resolves the problem but has the side effect of making eclipse forget everything about the workspace so I'm not sure it's a recommended way of fixing the problem.
I am running Eclipse Kepler on OS X Mountain Lion, and I had a similar problem. I deleted a project and tried to recreate it in the same location. Eclipse gave me an error saying that the project already existed. I discovered that if I close Eclipse after deleting a project, then reopen it, Eclipse finally 'forgets' the deleted project and allows me to re-create it.
(This question was posted over 1.5 years ago, and I'm guessing that Bruno already tried this and it didn't work. I just want to let others know that this solution worked for me now on Kepler.)
I had the same problem, with Egit and repositories that I deleted and imported back again, instead of importing as general project choose import as existing project.
maybe you can try to delete the folders:
"/your_workspace/.metadata/.plugins/org.eclipse.core.resources"
"/your_workspace/ProjectName"
If the Project was in a working set before you deleted it, you might have to manually remove it from the set.
Instead of deleting any file, rename it, so if whatever you try doesn't work, you can revert.
I was just putting the finishing touches on a flex project that loads files from a second project.
In attempting to delete a second project, I somehow deleted the project I needed. I confirmed that I wanted to delete the files. I have a backup but it is too old to be worthy of a roll-back.
Is there anything I can do?
You may use Eclipse's Restoring a Deleted Workbench Element option, but it wont works if you have deleted .metadata folder from workspace.
also see for visual help http://forums.techarena.in/software-development/1181287.htm
Hope it Helps
This is why version control exists....
Anywho, you can always look into software hard drive recovery.
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.
You need to delete the .syncinfo files. This is easily done (in most cases) by closing and opening Eclipse, however you can also do so manually as in the following:
To delete the cache, close Eclipse. The cache is stored in:
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects/PROJECTNAME/.syncinfo
So you can just find and delete all files named .syncinfo in
[workspace]/.metadata/.plugins/org.eclipse.core.resources/.projects
Quoted from this article: http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=868799
I just did a "Team -> Cleanup" and this exact error went away! I also got this error because I moved between machines and the path wasn't the same.
Using Eclipse 3.6 and the Subversion 1.6 plugin.
Update in 2016: Still works perfectly with Eclipse 4.5.2 and Subclipse 1.10.
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:
Team > Disconnect.
Quit Eclipse.
Blow away .metadata/.plugins/org.tigris.subversion.subclipse.*.
Restart Eclipse.
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.
I'm sure there are many causes with different solutions, but I found the one that worked for me 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.
I got the error when I tried to rename a class by changing the case from DAO to Dao in Eclipse.
I had to rename it to something like Dao2 and then was able to rename it to Dao.
What worked for me:
Do a "refactor - rename" on the project => after that do it again to rename it back to the original name.
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.
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.
Right click the project folder : Team -> Update to Head
This will bring back the directory. Delete it again and Commit
In my case I had the folders of the projects in the Project Explorer and just had to reopen the project
For me, this error message was caused by an out-of-date installation of Subclipse, and the underlying SVNKit and JahaHL libraries. I have been using TortoiseSVN outside of Eclipse to manage my project directories, and my recent upgrade to the 1.8.x series of (Tortoise)SVN tools broke my working copies for Subclipse.
All I had to do to fix, was go to Help->"Install New Software..." and click "Add..." to add a new update site. I picked the latest update site for the latest release on http://subclipse.tigris.org/servlets/ProjectProcess?pageID=p4wYuA and upgraded Subclipse from there.
Then all my existing projects just worked, and I could reconnect to the one I had already tried disconnecting from without problems.
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.
checkout the whole project to a temp dir, then I copied the first level .svn directory and replaced my working copy .svn folder with this.
http://blog.itopia.de/directory-svn-containing-working-copy-admin-area-is-missing/275
It woks for me.
I had added a png file to my project, but I got this error trying to rename or delete it. Cleaning and refreshing the project didn't do anything.
I went into the svn Team Synchronizing perspective, right clicked on the file and deleted it. That solved my problem.
Right click on the project and select Teams -> Switch to another Branch/Tag/Revision.
Select the appropriate Branch/Tag/Revision that the project should be tied to and click OK.
Give Eclipse some time to process the changes.
Restart Eclipse for the changes to take affect.
I just got this error when I was trying to update some .java files. The problem was I was trying to update the files but the folder that contains that files didn't exist in the path so when I sync and update the folder it works at the first try.
So, dont try to sync files, try to sync the folder.
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)
I too had this issue and I simply deleted the project from the workspace (leaving the files on the files system in tact).
I then imported an svn project into the workspace.
Import->SVN->Checkout Project From SVN.
I used my existing repository location to pull the files in.
This issue was caused when I changed Eclipse editions and used a Subclipse plug-in that was a version ahead of what I should have used.
I uninstalled the newer version and installed the correct older version and all worked well.