Upgrade JDeveloper 10g Subversion client

0 0
Read Time:3 Minute, 6 Second

JDeveloper provides a build-in Subversion client via one of its extensions. Although the functionality is limited (especially in 10g) it is essential for the handling of business components in relation to subversion, especially when it concerns refactoring and deletes. However, because of its limitations, most developers have installed another Subversion client; especially the TostoiseSVN is very popular. And this is where problems may arise.


The subversion client is available in different versions (1.3, 1.4, 1.5 and 1.6) and the structure of the local subversion administration files (the .svn directory) differs. This means that a lower version client does not recognize the working copy of a higher version client. It recognizes that the files are ‘under subversion control’ but does not understand how and it considers all files to be ‘new’. Secondly, a higher version client automatically upgrades the working copy. Thirdly, TortoiseSVN offers automatic upgrades to the latest version. By the way, the client version does not necessary need to match the server and it is not possible to install multiple versions.


Concerning TortoiseSVN, it really is advisable to have at least the 1.5 client. Especially the merge functionality is way better and easier to use than before. However, the JDeveloper 10g extension still is a 1.4 client (Note that the first 10g version ( is a 1.3 client). With this combination you’ll encounter issues, that require close attention, much discipline and may easily result in build problems.


For example, when you delete in JDeveloper a business component (actually often more files), the delete is not administrated in the working copy and the file is marked as ‘missing’. When you now do perform a subversion update, the file is back again . So you must not forget to manually delete the file via TortoiseSVN. It’s even worse with refactoring like renaming and moving.

To prevent these problems, it’s best to install TortoiseSVN 1.4 and disable the update check. However, the upgrade to version 1.5 is almost obligatory, because (amongs others) of the much better merge support. A typical catch-22 situation.


Fortunately, JDeveloper extension uses the svnkit (version 1.1.1) it is quite easy to upgrade to a recent version manually:

1.  Make sure to have TortoiseSVN 1.5 installed and disable the automatic update notification

2.  Stop JDeveloper

3.  Download the standalone svnkit 1.2.3 from http://svnkit.com/

4.  Unzip it

5.  Rename svnkit-javahl.jar to svnjavahl.jar

6.  Copy (and replace) svnkit.jar and (the renamed) svnjavahl.jar to the JDeveloper subversion extension directory, [jdev install dir]\jdev\extensions\oracle.jdeveloper.subversion.10.1.3

7. Copy the licence files

8.  Done, start JDeveloper

9.  Check the tools -> preferences -> Versioning -> Subversion. It now shows the upgraded version  :




I’ve tested it with and and and and expect it to work with and 2. With this does not work because it does not use the svnkit. I’ve tried hard, but didn’t succeed.

Note, the latest version of 11g (11g PS1 or includes a 1.6 client so you don’t need to update it. The older 11g versions have an 1.5 client (although the very,very first one has an 1.4 client that includes some 1.5 functionalities).

As mentioned in the comments, the same trick seems to work for an upgrade to 1.6.

Since it is so easy to do, I wonder why Oracle does not provide updates for their subversion extension.

About Post Author

Aino Andriessen

Aino Andriessen is principal consultant and expertise lead 'Continuous Delivery'. His focus is on Oracle Fusion Middleware ADF and SOA development, Continuous Delivery, architecture, improving the software development proces and quality management. He is a frequent presenter at Oracle Open World, ODTUG Kaleidoscope, UKOUG Technology Conference and OUGN Vårseminar. He writes articles and publishes at the AMIS technology blog (http://technology.amis.nl/blog/).
0 %
0 %
0 %
0 %
0 %
0 %

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

7 thoughts on “Upgrade JDeveloper 10g Subversion client

  1. Thanks for the tips.  I had to make a few more changes to get this working with my NTLM-authenticated/SSL repository:
    Copied jna.jar from SVNKit download into extension directory
    Edited extension.xml in the extension JAR (oracle.jdeveloper.subversion.10.1.3.jar) and added jna.jar to classpath entries (along with svnkit.jar, svnjavahl.jar, etc.). Be sure to write the updated extension.xml back to the meta-inf folder in the zip file.
    Added JDeveloper startup property in JDEV_HOME\jdev\bin\jdev.conf
    AddVMOption -Dsvnkit.http.ntlm=jna

  2. Hi,

    The svnkit 1.2.3 supports subversion client 1.5.x
    For a 1.6.x client you should use the svnkit 1.3.x

    I’ve succesfully applied this to JDev 10g and 11g


  3. Hi
    I’ve used your solution for
    JDeveloper, svnkit 1.2.3 and, subversion 1.6.5 recently.
    tools -> preferences -> Versioning -> Subversion – showed correct version, but when I’m trying to connect
    to subversion server, I got an error, as

    ERROR: svn: connection refused by the server
    svn: OPTIONS request failed on

    Have you got any idea, how fix this problem

  4. Hi!

    I’m new at this and i’m testing subversion with jdeveloper updating some simple JSPs in a local repository with 2 users.

    I’m interested in the lock-modify-unlock model, so I need command line to lock the files, but didnt succeed. I’ve just made the update you post here but I still get the message “this client is too old to work with working copy ‘.’ please get a newer subversion client” 🙁

    what i’m using:

    – JDeveloper
    – TortoiseSVN 1.5.9
    – svnkit 1.2.3

    what should i do? which version of what do I need? any ideas please!

    thanks in advance, have a nice day!

  5. JDeveloper Release 2 has svnkit version 1.2.0 installed, so 1.5 repositories should be working.
    As I’m using svn 1.6.1 I had the same problem, JDev did not understand my 1.6 working copy.
    I installed svnkit version 1.3.0-beta3 and it seems to be working.

    Groeten, HJH

Comments are closed.

Next Post

AMIS Query 18 May - Hotsos 2009 Revisited

The 8th of March 2009…The Oracle Performance Symposium in Irving, Texas, also known as the Hotsos Symposium was about to start… Four Dutch guys had the luck to attend this year: Jeroen Evers (Fameus), Toon Koppelaars (RuleGen), Gerwin Hendriksen (AMIS) en Marco Gralike (AMIS). We wanted to share some of […]
%d bloggers like this: