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 (10.1.3.0.x) 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 10.1.3.3 and 10.1.3.4 and 10.1.3.5 and 11.1.1.1.0 and expect it to work with 10.1.3.1 and 2. With 10.1.3.0.x 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 11.1.1.2.0) 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.
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
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
Ciao
Aino
Hi
I’ve used your solution for
JDeveloper 10.1.3.3, svnkit 1.2.3 and 1.3.0.5847, 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
The same fix works for SQLDeveloper 1.5.1.
Thanks for the tip!
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 10.1.3.4
– 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!
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