On most projects I used TortoiseSVN voor versioning with Subversion. It gives me a feeling of being more in control of my working copy. In the past I used JDevelopers built in versioning tool on a project, due to lack of administrator rights for installing Tortoise. And although you need to give it some time to get used to it, the versioning is pretty good actually.

On my current project I gave it a go again, since the customer is used to do versioning from inside the IDE (be it Eclipse or JDeveloper).

One thing that I remember to be hard to do was changing your subversion password. I remember that I could not find it in Jdeveloper 11g. And again in Jdeveloper 12c it was hard to find as well. So I started getting affraid to have to hack in the preference or property files. But it turns out that you can do it pretty easy from the tool. Be it that it is at a less obvious place.

In Jdeveloper go to the Team menu and choose Versions.

It will open the Versions Browser or Navigator:
You can right click on the particular connection (in my example the blurred one):

And here you can change your password.
You can also add or remove repository connections, import and export them. Which is handy because in SQLDeveloper there's also a Subversion client. Of course, since it's based on the same framework.


Some versioning features I'm happy about in JDeveloper:

• The pending changes tools is neat: it gives a nice overview of pending changes divided over tabs with incoming outgoing (your own changes), (updates from coworkers), and candidates (added files that are not versioned yet)
• Integrated in project navigator in JDeveloper, where you can do changes on file, project and application level.

I'm less happy about or getting used to:

• Versioning functionality is pretty much scattered over the IDE in different context menu's. Not only because of the different versioning levels, but the preferences are done at different places. See the Versions Navigator above, but I tend to search for preferences in the Preferences menu.
• There are folders that you don't want to have versioned, for example: files generated at build like compiled classes, processes and jar/war/ear files. You want to be able to set the 'svn:ignore' property for those. But those folders and files tend to be invisible in the project navigator. So you have to add the parent folders of those files and folders as a resource, set the property, commit and remove them as a resource again. 
• When I want to set keywords (like Id, author, etc.) for svn keyword replacement, JDeveloper doesn't know of the possible values. 

But for most jobs the SVN integration is impressing complete.

Happy versioning in JDeveloper!

At one of my customers I use JDeveloper 11g also as a subversion client. It is actually my first experience of the SVN implementation of JDeveloper, because I'm not able to install a tool like TortoiseSVN on this computer.

I'm pretty positive on the svn-client in Jdev. But unfortunately I haven't found any means to change the password in the UI. At this customer my windows-password has to be changed monthly, and the svn-password depends on it.

Jdeveloper stores the subversion connect info in the file

$APPLICATION_DATA\Roaming\JDeveloper\system11.1.1.6.38.61.92\o.jdeveloper.subversion\repositories.xml

(where "system11.1.1.6.38.61.92" depends on the Jdeveloper build).
The file looks like:

<?xml version = '1.0' encoding = 'UTF-8'?>
<svn-repositories xmlns="http://xmlns.oracle.com/jdeveloper/1013/svn/repositories">
   <svn-repository>
      <url>https://svn.customer.nl/svn/odc/odc-cmr/APPLICATION/source/trunk</url>
      <alias>Application Trunk</alias>
      <user-name>makker</user-name>
      <password>PlainOrEncryptedPasword</password>
   </svn-repository>
</svn-repositories>

Remarkable is the version number in the namespace (1013), since it really comes from my Jdev11g install.

When you first create the connection and give in your username/password via the UI, the password will be stored in here encrypted. But you can also give in an unencrypted password. So I entered my new password in plain format. And it works.

I haven't found how I can encrypt the password, what would, of course, be better. If anyone has a tip, then I'm interested.

You can also rename or delete the file,  then JDeveloper will ask for the new server connection.

Wouldn't it be nice to see what particular version you have deployed on your SOASuite test or production environment. How often does it occur that you thought you solved a problem but it still does not work on test or production. And after doing loads of tests and investigation you encounter that not the version you expected was deployed?

This week I tried to add the svn Id keyword in a piece of comments in the WSDL of the service. But it turns out that at deployment the SOASuite filters out the comments. So that won't work.
But since I'm writing this blog you might expect I found a trick...

First add the svn keywords  to the files you want to have the properties in. In this particular case it would be the service wsdl. This can be done with Tortoise SVN by right clicking the file, and choose TortoiseSVN->Properties. Then clicking the new button you can choose for Keywords:


 After that you can check the SVN properties you like to use. For most cases ID gives you all the info you need.
 Clicking OK will get you back to the properties screen, where you'll see:

Mark that in the list of checkboxes the Id-keyword is all in capitals, while in the comma-seperated list of keywords in the properties pane, the Id-property is in the correct spelling (one capital I).
The trick is to add the property as a namespace declaration as:

  xmlns:svnid="$Id$"
  xmlns:version="1.1"

After a SVN-commit this will expand to:

  xmlns:svnid="$Id: ImportEquipment.wsdl 765 2012-06-08 13:07:10Z makker $"
  xmlns:version="1.1"

Like such:

The reason I added a "version" namespace as well is that your wsdl will not change every time the service changes. Often you change a bit of BPEL or XSL or something like that, while your interface, the wsdl, stays unchanged. To force SVN increase the revisionid in your wsdl, you can change the xmlns:version namespace.

This morning I tried to install Subversion 1.5.1 on Red Hat Enterprise Linux 4. This turned out to be a slightly more complicated than just easy. Because I ran into some dependency issues.

I downloaded Subversion 1.5.1 at: http://summersoft.fay.ar.us/pub/subversion/1.5.1/rhel-4/i386/.

Running rpm gave me the following depencency issues:

rpm -ihv subversion-1.5.1-1.i386.rpm
error: Failed dependencies:
apr >= 0.9.7 is needed by subversion-1.5.1-1.i386
apr-util >= 0.9.7 is needed by subversion-1.5.1-1.i386
libneon.so.27 is needed by subversion-1.5.1-1.i386
neon >= 0.26.1 is needed by subversion-1.5.1-1.i386

To solve this download the following libraries:

• The apr and apr-util version 0.9.12 packages at: http://summersoft.fay.ar.us/pub/subversion/1.4.6/rhel-4/i386/
• The neon and neon-devel version 0.27.2-1 packages at http://summersoft.fay.ar.us/pub/subversion/1.5.1/rhel-4/i386/

Summerset is one of the suppliers of the subversion binaries. I found that they did quite a good job on providing the necessary libraries for the different Linux flavors. At least the ones I needed. However, although subversion 1.5.1 needed the arp libraries, they were not found in the subversion/1.5.1/rhel-4 folder. So I fetched them from the subversion/1.4.6/rhel-4 folder.

Since subversion needed a specific neon-shared-object, I could not do it in one go, because at dependency check the system-object was not there. Therefor I first installed neon and neon-devel:

rpm -ihv neon-0.27.2-1.i386.rpm neon-devel-0.27.2-1.i386.rpm
Preparing... ########################################### [100%]
1:neon-devel ########################################### [ 50%]
2:neon ########################################### [100%]

Then the rest could be installed in one go:
rpm -Uhv subversion-1.5.1-1.i386.rpm apr-0.9.12-2.i386.rpm apr-util-0.9.12-1.i386.rpm
Preparing... ########################################### [100%]
1:apr ########################################### [ 33%]
2:apr-util ########################################### [ 67%]
3:subversion ########################################### [100%]

So I now start off with creating my repository.

Lately I've been introduced into the ease of use of subversion. I now use it on my laptop to keep track of my projects. It's surprisingly easy to setup a repository and to use it. Maybe I should do a posting on that in the near future.

I also setup a local synced repository that I use to get a local copy of our central project repository. However, last week I started by accident this repository server twice, and stopped the sync-run by ctrl-c to resolve this. After that I got a:
"Failed to get lock on destination repos, currently held by makker-laptop" message repeatedly.

I got the solution on: http://journal.paul.querna.org/articles/2006/09/14/using-svnsync/.

However the exact command mismatched for me (I don't know how version dependent that is).

What I had to do is to delete the lock by removing a lock-property. The command for this is:

svn propdel svn:sync-lock --revprop -r 0 .

In Pauls blog he suggested the svn-command propdelete, but this should be propdel. And I had to make up that for the repository you have to give in the link to the svnserver that runs the repository.

For example:
svn propdel svn:sync-lock --revprop -r 0 svn://localhost:3904

This worked, and got me syncing my repositories again.