Using Eclipse v3.1 and Subclipse v1.0.3 with newer versions of TortoiseSVN

Posted by Dan on Oct 26, 2006 @ 12:17 PM

I recently upgraded a few of my installation of TortoiseSVN to the latest revision. Every since doing this, I've been unable to use Subclipse v1.0.3 (in Eclipse v3.1) to change repositories that have been touched with TortoiseSVN. This is because the newest version of TortoiseSVN using the v1.4 of the client libraries and Subclipse v1.0.3 is based on the old v1.3 client files.

Since one of my development boxes only has Eclipse w/Subclipse, it's been a pain to deal w/this compatibility issue. So, this morning I set out to find a solution to this issue.

Fortunately, I was able to find a post by Mark Phippard that addresses solving this issue (while for Subclipse v1.1.6 anyway.) I did run into an issue that apparently doesn't affect the newer version of Subclipse, but since I'm still using Eclipse v3.1 at the moment, I'm stuck using Subclipse v1.0.3.

Anyway, here are the steps I needed to take:

UPDATE:
I originally goofed up the instructions a bit, they should be correct now.
  1. Close Eclipse.
  2. Download the following files:
  3. Unzip the files into some temp sub-directories (or using a zip extraction GUI, like WinRAR, just copy the files from the archives.)
  4. Copy all of the .DLL files from the /bin/ folder on the svn-win32-1.4.0.zip into the ./plugins/org.tigris.subversion.javahl.win32_1.X.X in your Eclipse folder. (where win32_1.X.X is most recent version of the JavaHL folder.)
  5. Copy the libsvbjavahl-1.dll file from the svn-win32-1.4.0_javahl.zip into the ./plugins/org.tigris.subversion.javahl.win32_1.X.X in your Eclipse folder. (where win32_1.X.X is most recent version of the JavaHL folder.)
  6. Next copy the libdb44.dll file from the ./plugins/org.tigris.subversion.javahl.win32_1.X.X folder and place a copy of it in the root Eclipse folder (the same one with the eclipse.exe)
    NOTE:
    Until I copied the libdb44.dll into the root Eclipse folder, I kept getting errors that Eclipse could not find the DLL. I guess you probably could get away with only copying it in the root folder, but it's working and I'm not going to fudge with it. :)
  7. Open Eclipse.

If all goes well, you should now be able to use Subclipse with SVN repositories that have been altered with any SVN v1.4 client (like the newer versions of TortoiseSVN.)

NOTE:
For some reason Subclipse would not remove the old "dirty" markers on my files until I actually committed a file in that folder. I tried refreshing the folder and restarting Eclipse, but committing a changed file seemed to fix the false "dirty" markers.
Categories: Java, Source Code, HTML/ColdFusion, qForms, JavaScript

6 Comments

  • Hey, do you have the names of the zips mixed up? I found the libdb44.dll in the svn-wind32-1.4.0.zip. The only DLL I found in svn-win32-1.4.0_javahl.zip was libsvbjavahl-1.dll.
  • @Daniel:

    Good catch. I've revised the instructions--hopefully they're accurate now!
  • Are you happy with Tortoise? I've been wanting to use Subversion at work. David M. recommended http://www.unfuddle.com but that costs money, and it's hosted offsite. Why pay for something that's free, and that could be hosted in house...
  • libdb44.dll just needs to go somewhere in your PATH. The Eclipse root folder works because it is the "current directory". Subclipse 1.0.4 will be out in a couple of weeks and it will include the 1.4.x libraries.
  • @Mark:

    First, thanks for the great work on Subversion & Subclipse.

    I knew it was just needed in your path, but I didn't want to add anything to my existing path and didn't want to pop the DLL in an inappropriate place (like the Windows folder.) This made the Eclipse folder the logical place.

    I played around w/trying to add a path to the JVM for Eclipse, but only spent a couple of minutes playing around with it.
  • Thank you very much for this workaround!

    To remove the "old" dirty markers you have only to "touch" the file (insert+delete blank, save) in eclipse.

Add Comment

Leave this field empty