Subclipse on Ubuntu: 'Folder " does not exist remotely', Connection refused error
So I have been banging my head against the wall for days on this one. When I initially set up Subclipse and first connected to my local SVN repo, everything worked great. Not sure what's changed since then, but now I keep getting errors when trying to access the repo.
In SVN Repository Exploring perspective, if I double-click on my repo I get a popup that says "Problem Occured - Folder " does not exist remotely". In my console, I get this error:
Connection refused svn: Unable to connect to a repository at URL 'svn://userid@localhost/home/userid/myrepository/java' svn: Can't connect to host 'localhost': Connection refused
I have: Eclipse Juno Ubuntu 12.04 Subversion 1.7.8
I initially started off with Subclipse 1.6 and JavaHL 1.6 but have since upgraded to Subclipse 1.8.3/JavaHL 1.7.8.1 in my efforts to get everything working again. I even uninstalled Eclipse and reinstalled, re-installed Subclipse and JavaHL, adding the JavaHL path to eclpise.ini... still can't access the repo.
I was accessing the repo locally in subclipse via "svn://userid@localhost/svn/home/userid/myrepository/java". I can access this repo locally from the command line just fine, and I can access this repo from another machine on my network using svn+ssh just fine.
What am I missing?
Answer
If the repository is local, you should be using a URL like file:///home/userID/myrepository/java
To use the svn:// protocol you must have svnserve running. The URL would then be something like:
svn://localhost/myrepository/java
When you use the svn+ssh:// protocol, the SSH daemon starts and launches svnserve in --tunnel mode within the SSH session. So it does not need or use a normal svnserve daemon server that may be running.
FWIW, it would probably be a good idea to run svnserve, but that means you will also need to configure it. But I would not use file:// URL using SVNKit. If you use JavaHL exclusively, then it is fine, but I would not let SVNKit write directly to my repository. Even though they do a great job testing and maintaining compatibility it is just easier to run svnserve and let SVNKit talk to it via the protocol.