views:

2164

answers:

3

What actually happens to the file system when you do a Subclipse Share Project on an Eclipse project that was externally checked out from Subversion? All the .svn folders are already in place. I get an error when I try to Share Project the right way, and I'd rather not delete and re-checkout the projects from the SVN Repository browser.

+5  A: 

Dunno exactly what happens within eclipse, I presume it does some funky stuff in the .metadata directory of the workspace. That said, I would recommend the following to get eclipse to learn about the svn settings of the project:

  • Delete the project from the workspace (keep "Delete project contents on disk" unchecked)
  • File > Import... > General > Existing Projects into Workspace
  • Browse to the folder containing the original project(s) of interest
  • Import the projects into your workspace

This seems to have the side effect of subclipse noticing the subversion settings when importing the "new" projects into your workspace.

Rob Oxspring
Good call. That worked fine.
jodonnell
The same approach works for CVS projects as well.
John Meagher
+1  A: 

The Share Project action is intended to commit the first version of a project, i.e. one with no .svn metadata in place. It will get upset if it sees .svn directories already there. As Rob wrote, the way to get that checked-out project into Eclipse is to use the import capability.

Oisin Hurley
A: 

I'm not sure what version of Eclipse you are using or whether this will apply since I'm using Subversive instead of Subclipse. When I use the share project feature to commit the project into svn when I already have all of the .svn directories in place, I get a choice of like "Use current project settings" and then eclipse automatically reattaches the project svn information to the team integration. You can screw it up if you try to enter different information.

Jay R.