Why does Subclipse only work in some Ecliplse workspaces and not others?

Question

I'm using Eclipse with Subclipse to do some perl development. The Subversion repository is setup like:

• /repos /repos/dev/
• /repos/dev/crontabs
• /repos/dev/crontabs/script1
• /repos/dev/crontabs/script2
• /repos/dev/daemons
• /repos/dev/daemons/script3
• /repos/dev/daemons/script4
• /repos/dev/tools
• /repos/dev/tools/script5
• /repos/dev/tools/script6

On the file system, I have the entire /repos/dev tree checked on locally to ~/dev and have created three Eclipse workspaces, one each in "~/dev/crontabs", "~/dev/daemons" and "~dev/tools".

Here is where things get weird. In the daemons and tools workspaces SVN works properly. I don't see the .svn directories and I can do all the various SVN stuff (e.g. commit, update, cleanup) in the TEAM dialog. However, SVN isn't working in the "crontabs" workspace. The .svn directories are visible and none of the SVN dialog options are available.

In all directories, I can use the command line SVN tools and everything works fine.

Here are some more details.

• Mac OS X 10.5.6
• Eclipse Platform - Version: 3.4.2 - Build id: M20090211-1700
• SVNKit Library 1.2.2.5405
• SVNKit Client Adapter 1.5.6.1
• Subclipse 1.4.8
• EPIC 0.5.46

I've tried deleting the deameons .metadata and realted .profile files to try to clear it out and start a fresh workspace, but that didn't work.

Anyone seen this type of behavior before and/or know a way to get the SVN commands to work in all the workspaces instead of just some of them?

UPDATE: I should also mention that there is a bunch of other assets in the /dev directory that I don't use Eclipse for. So, I'm using the command line SVN tool in conjunction with the SVN functions in Eclipse. Everything was originally checked out with the command line tool and then I'm just using Eclipse for the commits. What's throwing me is why it works in two subdirs, but not the third while the command line works 100%.

Answer 1

When you switch workspaces, all the settings, etc. from other workspaces are ignored.

Instead of checking out the whole trunk, and creating 3 workspaces that coincide with your repository structure, create 3 workspaces, and checkout the relevant portions of your repository as projects for each workspace.

Answer 2

When you create a new project and import files into it, Eclipse does not assume that a project is version controlled. You have to explicitly tell it using the Project's Team -> Share Project... dialog.

Once you choose the correct directory, Eclipse should tell you that the project is already shared in that location, but activate the SVN commands in Eclipse for it anyway.

Answer 3

Got the same problem here, with individual workspaces.

• Linux Mandriva 2009.1
• Eclipse Platform version 3.4.2, Build id: M20090211-1700
• Subclipse 1.4.8
• SVN Client adapter: 1.5.3
• SVNKit Library 1.2.3.5521
• SVNKit Client Adapter 1.5.6.1

I too use both Subclipse and the svn command line client (version 1.6.1 (r37116)), and things were working fine prior a Mandriva update, so I was wondering if it could be that my version of Subclipse is incompatible with my version of svn.

Answer 4

I'm not sure I totally follow all that. And the Subclipse plugin isn't as polished as the CVS plugin. But if you copy a project into a workspace and it includes Subversion context (.svn folders), as Bemose has noted, that isn't meaningful to Subclipse.

In theory, when you use Team/Share and you get the warning message, you can give the go-ahead and it will nuke the existing .svn files and build new ones that are proper. If you're lucky that will even work. It does with CVS, but, as I've said, Subclipse can be more of a problem.

Your best best is to check the projects out into your workspaces using the Eclipse subversion perspective and the "Check out as Eclipse Project" option.

If you absolutely feel compelled to construct your project directories from the command line, use the Subversion export command, not the checkout command. Exporting omits the ".svn" directories, so Eclipse can do its thing without interference. However, you will have to do a Team/Share to connect the exported project to the subversion repository.