Installing Subclipse w/ JavaHL (aka CollabNet Subversion)
- Download CollabNet Subversion for your operating system (Linux, Windows, MacOS X). This provides the JavaHL layer so that Subclipse can talk to SVN repos using pure Java (but not SVNKit). Install it.
- Download Eclipse 3.4.1 (or Fedora Eclipse). Start it up, making sure to pass in
-Djava.library.path=/opt/CollabNet_Subversion/lib(linux only).- Help > Software Updates... > Available Software > Manage Sites... > Add... > http://subclipse.tigris.org/update_1.4.x
- Install the whole site. Restart when prompted.
- Window > Preferences > Team > SVN > SVN Interface > Client > JavaHL (JNI)
Well, I feel I've been remiss in ranting about Subclipse. Turns out a fresh Eclipse + a fresh install (and a lot of trial and error / googling has fixed things.
You have not exactly given us a chance to help you with your Subclipse issues.Mark, you're right, Subclipse does work -- it's just not the most straightforward thing to install. And when it breaks suddenly and for apparently no reason, losing hours of productivity to fighting w/ source control instead of writing and committing code, it's VERY frustrating, especially considering that Eclipse's CVS support Just. Works.
Does the JavaHL library exist in the folder you pointed to?Well, given the wiki doesn't actually say what file(s) are supposed to be there, I had to guess. I have
/usr/share/java/svnkit-javahl-1.1.4.jar and /usr/share/java/svnkit-javahl.jar (a symlink to the previous). Is that what Subclipse / Subversive are looking for? No idea.
Do the preferences say "Not available"?They do. After much surfing, googling, testing, registering to download, waiting for a password, cursing, downloading and
rpm -i ... I finally figured out that all I needed to do was get CollabNet Subversion Command-Line Client v1.5.4 (for Red Hat Linux), and (as noted in the wiki), add -Djava.library.path=/opt/CollabNet_Subversion/lib to my Eclipse startup. Could you save others this search by linking to the downloads page from the wiki? Or even linking to it from the Downloads page??
I think somehow an old version of their JAR is being loaded by your Eclipse and not the one in their plugin. Do you have their JAR installed in your Java extensions folder or something?Reinstalling Eclipse and purging some jars of unknown pedigree & version seems to have worked. I have svnkit 1.1.4 in the above folder (
/usr/share/java), and org.tmatesoft.svnkit_1.2.0.4949 in a linked folder in my dropins/.
Finally, as to your History error, Subclipse does not have this problem, but I know the cause. Your history view is setup to "Show Merged Revisions". I would assume that Subversive exposes this as an option in the UI that you can turn off. That is what we do in Subclipse.I expected to find this as an option under Window > Preferences -- some digging showed me that, no, it's under the view's menu > Include Merged Revisions. Thanks for the tip!
Anyway, we also catch that exception when talking to older Subversion servers and just make the request again without asking for the merged revisions. If you have not already filed a bug report with Subversive you probably should.Good idea -- see bug 257669. I just want something that will work, won't crash Eclipse, won't freeze up during an update, won't leave dozens of "not really there" files in my Synch view (that magically disappear when I click the 'collapse all' button in the view), won't throw errors when I try to look at file histories.
So, for the moment, I'm back to Subclipse. I've upped the permgen and heap for Eclipse to 400M and things are working again. Seems large projects + SVN = crashing/freezing/OOM errors. Maybe JavaHL won't be so greedy? We shall see.
6 comments:
I will try to update the Wiki based on your comments. The Wiki is an attempt to explain the JavaHL issue to users so that they can understand how to get it working and also why it cannot simply be distributed with the plugins.
To answer some questions:
The JavaHL path you need is the one to the native library. The JAR comes with Subclipse/Subversive you need to supply the library (libsvnjavahl-1.so). This is usually in /usr/lib/jni or /usr/lib or /usr/local/lib. One of the problems in dealing with Linux is that the location varies.
I think the reason you were not able to use SVNKit is that you had a copy of its JAR in that global Java extensions folder. I am surprised Subversive did not have the same problem. I will contact the SVNKit authors to see if there is something we could have done.
I did not link to the CollabNet Subversion binaries because I maintain those binaries and did not want to seem like I was just promoting them as the only option. You can use the JavaHL from your distro, I think you just were not entering the right path.
Well, tried the JavaHL layer for the first time today and got this trying to commit a change to a file:
RA layer request failed
svn: Commit failed (details follow):
svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request for '/repos/devstudio/!svn/act/4f5425fd-c29d-4f84-8c85-826cdfb06571'
So, I've gone back to SVNKit, which does work. Will the madness never end?
A 403 would imply your credentials were not valid. JavaHL and SVNKit do each have their own distinct cache so perhaps the one for JavaHL has something unexpected from a previous usage? JavaHL shares the same cache as the command line so in theory a commit using the command line client should have the same problem.
You can rm -Rf ~/.subversion/auth to clear your cached credentials. You should then be prompted again in Eclipse the next time you need to provide them.
Searching for "svn: Server sent unexpected return value (403 Forbidden) in response to MKACTIVITY request" does give some hits though. Were you doing something with Maven when you did this? I see a lot of people with Maven problems. Looks like it is a bug in SVN since 1.5.1 release.
Wasn't doing anything w/ Maven, but your suggestion to blow away the cached credentials *did* work. Thanks!
(I wonder if any of this week's rant should be digested into a FAQ on your site? I can't be the only person with these issues.)
rm -Rf ~/.subversion/auth is my new phrase of the day, cheers mate :D
It's most likely to do with case sensitivity on the repo URL. It's case INSENSITIVE when checking out but case SENSITIVE when committing.
I scratched my head for a couple of hours with exactly the same problem, that checkout is not a problem but a 403 forbidden comes when trying to commit.
I.e. if the correct repo URL is http://acme.com/svn/Acme but you checked it out as http://acme.com/svn/acme it won't work.
Post a Comment