davidb dives in   Archives

subversion subclipse mac os x and linux

I’ve been moving my small work group from CVS to Subversion. Not that we make huge demands on our CM system, but Subversion is an obvious step up.

###Server Problems

My first real attempt (beyond just skimming the subversion book and installing an internal test system that I only let live for a few days) was to install version 1.0.8 on our group’s web server box, running Fedora Core 2. This was a pretty easy install as FC2 comes with an rpm for subversion 1.0.8. It is practically done for you. You just need to decide on a repository strategy and a backup plan. It all went swimmingly well until we started to tentatively use it. At that point, I discovered that the Berkeley DB database it was using got corrupted at the drop of a hat. This was bizarre, and I still don’t know what the issue was. We spent about a day searching the Internet for others experiencing the same problem. Nothing. Not being willing to seriously debug this issue, I backed off for a bit. A few weeks ago, I tried again, this time with version 1.1.0-rc4 and the FSFS filesystem, instead of BDB. A few cvs2svn runs later, I was comfortable that this install of subversion was stable and fine.

###Enter Subclipse

I’ve been using the Eclipse IDE for my Java development for a few months now, and I had gotten somewhat used to using it for some of the CVS management of my projects. (This after 10 years or so of using the command line for all CVS work). Of course, there exists a plugin for Eclipse for working with subversion, Subclipse. And, of course, once I got the latest version of this plugin (0.9.22 or 21), I couldn’t get it to work. Not on linux (my normal development platform), nor Mac OS X, my teammates main platform (and probably my future development platform). The problem was, essentially, that Subclipse uses javahl, a JNI interface to the C subversion client libraries, and it was missing or mismatched on both platforms.

####Linux

On my Linux workstation, the first problem was that javahl wasn’t built or installed with the subversion RPMs. I had already been hacking an existing subversion RPM to be a 1.1.0 RPM, and just had to modify it further to actually build the javahl stuff, and then put it in a separate RPM. That took a few hours. Then I had to come to the slow realization that the patches from my original RPM were causing the javahl stuff to not link correctly. Then I had to realize that my eclipse installation wasn’t finding the shared library (I solved that by creating a shell script to put /usr/lib in LD_LIBRARY_PATH before launching Eclipse). Note that on Linux, before I got the javahl stuff to work, it would use the subversion command line tools, but this produced irritating error dialogs all the time. It just wasn’t the smoothest solution out there.

####Mac OS X

(I’ve been using the subversion package from metissian.com for Mac OS X. I like fink, but this was so much easier) When I first tried Subclipse on Mac OS X, it just caused the JVM to die. Later, after the latest Java 1.4.2 update, it just didn’t work. This was a similar issue: console would spew forth error messages that I could tell immediately were because there was a mismatch between the installed javahl stuff and Subclipse (no problems loading the shared lib on this platform, the metissian package puts the shared lib in a valid spot). After struggling with this for a day, just updating to the 1.1.0 version of the package solved everything.

####The Future

In the future, I’m hoping that Subclipse switches to a native Java subversion library, which will hopefully make Subclipse always work right out of the box.

Written on Oct 22, 2004.

comments powered by Disqus