same in my case: .svn dirs were there, but my project didn't support svn actions.

after a bit of poking it turned out that subversive plugin just disappeared after a forced quitting eclipse.

the solution was to (re)install subversive, and now everything is fine again.

cheers v.

update: i have switched eclipse to a new version that just didn't have the plugin installed, which is the reason why i had to install it from scratch.


this worked for me: right click-> tortoisesvn -> settings -> icon overlay properties, selecting shell as status cache. click ok, refresh page.


i can reliably reproduce this problem—it happens when checking out certain maven projects by running "check out as maven project…" not on the folder containing the pom itself but on a parent directory (such as "trunk"). in this case subclipse checks out the project without any complaints, putting it in a workspace directory with a placeholder name such as maven.1424425443350. inside this directory it creates a subdirectory with the name of the maven artifact. this confuses both subclipse and subversion: subclipse, as we've seen, immediately forgets that the project is under version control, and if you invoke svn status from the command line in the maven.1424425443350 directory, it will tell you that the directory is under version control but that all the version-controlled files are missing.

none of the workarounds presented in the other answers will work if this is what caused subsclipse to forget its svn connection. instead, the only solution is to delete the project and check it out again, this time making sure that the checkout is performed on a directory containing a pom rather than some higher-level directory.

a better overall solution would be for subclipse to refuse to run "check out as maven project…" on directories which don't contain a pom, or else to better handle cases where it tries to do so anyway by searching subdirectories for maven projects.


i was using two svnkit implementations (1.7.x and 1.8.x) simultaneously with the svn repository version (1.8.x).

as a result the team -> share projects... always requested a commit message. obviously, svnkit 1.7.x was used which is not compatible with svn 1.8.x.

after removing svnkit 1.7.x eclipse used the only available correct svnkit version 1.8.x and everything worked as expected.


my .svn metadatas folder were deleted.

none of the solutions here worked for me (close/reopen project, delete/reimport, still unlinked)

following steps worked for me:

  • before all backup source project project/ folder to bak/
  • eclipse > on project:
    • delete project, choose yes for "delete content too?"
    • team > checkout as fresh project, recursive
    • restores all up-to-date content and the .svn folders
  • close eclipse
  • copy / override from bak/ to project/:
    • optional, .classpath and .project files ⇾ restores project (java) natures, setup, build path, ... if yours was modified compared to server version (i needed to)
    • optional, all source files and folders ⇾ restores your latest local changes (i needed to)
  • open eclipse
  • eclipse > file > import project

the project is now restored, it builds and is linked to subversion again, with the latest local recent changes kept if any.


without knowing what platform you're on, i don't know if your problem is similar to mine. however, i have recently (actually on two different platforms!) had issues where an update to subversive (or perhaps eclipse itself, not clear) caused the connectors to no longer load. without the connectors, subversive cannot connect to a project. but eclipse isn't going to lock you out of your project over that, it'll just remove the svn-related functionality.

look at the errors view, which is a log of eclipse's various errors (class-not-found exceptions, etc.) and see if there are any lines that related to the subversive components. unfortunately, i can't really recommend a solution-- on my mac osx platform it was enough to re-install the subversive core elements and connectors. on my linux machine (possibly due to an os upgrade) i'm having to completely re-install eclipse, as too much cruft has accumulated for me to be able to fully investigate it.


in the juno release with subversive, i did:

  • file/import brings up the import popup.
  • from there, select general/existing projects in to workspace.
  • in the next pane, you select the root directory. then it will show you all the subdirectories. they'll all be selected by default.
  • unselect the ones you don't want.

it will then "import" your existing directory, which can be used in-place they are already located inside your workspace directory.


i had the same problem and this forum helped me in finding the right answer.

my earlier project was configured using subclipse. the new eclipse had subvesive.

installing subclipse helped me get back the svn options under team!

hope it helps someone else.


anshu prateek


from eclipse, i closed the project(s) and reopened which resolved the problem. all by svn links are back for all projects in my workspace.


addendum: it turns out that my problem manifests when i start eclipse outside the company vpn, with a project in the workspace that is attached to a svn repository inside the vpn. fortunately, switching eclipse svn plugins from subversive to subclipse did solve it.



just doing team -> share project (per the answer to this question provided by @paul whelan) did not work for me. the share project wizard acted as though the project was not already in svn (even though the .svn folder was present for my project).

i ended up resolving the issue by uninstalling the subversive and javahl add-ons (via help | about eclipse | installation details button | installed software tab | uninstall...), and then reinstalling subversive. when prompted after restarting eclipse, i opted to install the svnkit connector rather than the javahl connector.

after having done that, when i once again tried team -> share project..., eclipse correctly recognized that my project was already present in svn, and it successfully restored the connection.


i found an easy way just reimport the project


if you are using sublipse as your svn provider i recommend doing the following

team -> share project is usually enough to connect the metadata.

(that is, assuming that the .svn files are still there which they seem to be if you can work on the command line).

hope this helps as to why this would happen i have no idea

Related Query

More Query from same tag