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:
- http://subversion.tigris.org/svn_1.4_releasenotes.html
- http://www.oracle.com/technology/products/jdev/htdocs/partners/addins/exchange/subversion/subversion.html
- http://forums.oracle.com/forums/thread.jspa?messageID=1493871�
![CTAS on a Table with Nested Tables]({"aperture":"0","credit":"","camera":"","caption":"","created_timestamp":"0","copyright":"http:\/\/seattletimes.nwsource.com\/ABPub\/2012\/08\/02\/2018836700.jpg","focal_length":"0","iso":"0","shutter_speed":"0","title":"","orientation":"0"} "CTAS on a Table with Nested Tables")
Here is the workaround:
http://forums.oracle.com/forums/thread.jspa?messageID=1772827
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.
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