JDeveloper and Subversion

Aino Andriessen 3
0 0
Read Time:1 Minute, 35 Second

Like many others, we use Subversion as our preferred source control system (scm). Since a few months an official JDeveloper extension is available which makes our ADF development and source control much easier; e.g. when you remove a Business Component (BC) like a viewObject all the objects, like the XML file and the impl class and the resourcebundle, are now marked for deletion (instead of reported missing). However, recently I encountered some troubles; that is JDeveloper did not recognize anymore that the files were source controlled. What happened ?!

I started recently at a new project for DTSI in Nouméa, New Caledonia, and had to install my development environment like JDeveloper (10.1.3.1), the subversion command line, TortoiseSVN, Maven etc. etc. I checked out the project from within JDeveloper and everything was still fine. I then did some external changes and committed and updated the project using TortoiseSVN and when I went back to JDeveloper the only versioning option available was to ‘add’ the files 🙁 .

It turned out that the format of the Subversion working copy, i.e. the administrative files in the .svn directory on your local machine, have changed as of version 1.4. All the clients that I downloaded now use that format and automatically convert the working copy to that format… except JDeveloper, that still uses the 1.3 format, so it just fails to recognize that it’s a subversion working copy. By the way, this does not affect the Subversion Navigator which is still fully functional. Currently the only solution is to downgrade the other subversion clients, like the subversion command line and tortoiseSVN, until a new version of the JDeveloper extension is available.

Resources:

 

Ile des Pins, Baie de Kuto

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/).
Happy
Happy
0 %
Sad
Sad
0 %
Excited
Excited
0 %
Sleepy
Sleepy
0 %
Angry
Angry
0 %
Surprise
Surprise
0 %

Average Rating

5 Star
0%
4 Star
0%
3 Star
0%
2 Star
0%
1 Star
0%

3 thoughts on “JDeveloper and Subversion

  1. I ran across the same problem after upgrading to the newest version of TortiseSVN. According to the Subversion documentation, the 1.4 client upgrades any working copy it accesses to the new format. The version of JavaSVN that JDeveloper uses is a 1.3-based client thus can’t read the 1.4 format.

    I think I read a thread on Oracle’s JDeveloper forum where someone had replaced JavaSVN with a new version or was using a different client altogether in order to access a 1.4 working copy.

  2. Would you be using JDeveloper and TortoiseSVN on the same working copy? A subversion 1.3 client can check out / update / commit from a subversion 1.4 repository but as soon as a subversion 1.4 client operates on a 1.3 working copy. A modification occurs to the .svn directory so that a subversion 1.3 client does not understand the .svn structure or format. This is what I have found. I believe that the subversion 1.4 repository is using different structure from 1.3. and that a seemless conversion is performed when talking to 1.3 client

Comments are closed.

Next Post

Security as a Individuals footnote

I have written this article over and over again, looking for a way to keep the depth of technical information leveled for the intended audience. I found it almost impossible to write this article in such a fashion, that It would be interesting for more then network administrators and system […]
%d bloggers like this: