Subclipse is normally a component of your Eclipse IDE. It manages the interaction that you have at your repository. Once you start using it, sometimes going back to the command-line of things can seem tough (unless you’re a true power user).
If you were like me a few months ago, your Subversion repository had a self-signed certificate, and only allowed SSL connections for repository access. There was one problem. Subclipse access to the SSL based repository would error out, returning such things like:
svn: PROPFIND request failed on ‘/svn’
svn: decompression_failure: remotely generated; fatal
svn: PROPFIND request failed on ‘/svn’
svn: decompression_failure: remotely generated; fatal
The error has changed since I first started trying to fix the problem, but generally I got PROPFIND errors.
Having no real knowledge of Java internals, this problem forced me to go into Windows for awhile (deadlines to meet, things to kill) since SSL worked flawlessly there. The problem wasn’t with subclipse, but rather it was with the Java JDK that I had installed. There are a multitude of solutions to this problem of course, and i’m not the first to post about it (the problem also varies from person to person).
Operating on an Ubuntu system, I tried installing stuff for JNI, upgrading my encryption strength for JavaSVN.. — if it was on Google, I tried it.
I finally settled on the following (going off of the installation information here) :
1. First, I had to find the JDK. There might be later versions, but I used the one in the example. Sun’s site can be a little hard to navigate, so I just plugged the self-extracting file into a search engine.
The first link that came up had a bunch of download options. I hit the radio button for “Accept License Agreement” and after the page reloaded, proceeded to begin downloading the Linux self-extracting file.
Once finished, I did as the article noted (the $ notation denotes regular user, # for super-user):
$ bash jdk-1_5_0_06-linux-i586.bin
If you want to skip over the license (you’re probably better off reading things you agree to though), you can hit ‘q’ since the license agreement is piped through `more`. Answer `yes` to continue afterwards.
(The below might be Debian/Ubuntu specific, but please try)
$ sudo mv jdk1.5.0_06 /usr/local/
$ sudo ln -s /usr/local/jdk1.5.0_06/bin/* /usr/local/bin/
$ java -version
The above `java -version` command should spit out the version. You should see something like:
$ java -version
java version “1.5.0_06”
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05)
Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing)
Now restart Radrails, and try to import a project. It should work. The first signs of success are a username/password prompt for your repository (if you have one), and then a directory listing of your projects.
Thanks to the folks over at debian-administration.org for publishing a good article.
Please note that you can probably use repository-based JDKs (apt, etc), but I have personally tried these without too much success on my own. If anybody gets this working with a stable repository version, by all means leave a comment so that others will know.