Friday, February 08, 2008

At what level should I version my source code? - Alternate Takes

So now you know that I'm a Blues fan. One of Blues most revered artists was Robert Johnson. There are only a very few recordings of him - done between 1937 and '39 - just 29 different songs, but there are alternate takes bringing his total recordings to around 40 songs. Maybe he was striving for perfection, maybe different styles suited different audiences or even his moods, but these alternate takes add to the legacy left by him. Some blues fans have their own favorites but I love them all!

Recently I've been speaking with a number of JDeveloper/SVN users concerning the level at which they version their code. While I still maintain that the best way is to create a working copy at the Application level there are times and development process requirements when this isn't practical or possible.

Take this example: A team development with one Application split into many Projects. The Application is under source control using SVN. Their development process mandates commits are done per Project. There are a number of ways to achieve this, here are my suggestions for a team member to work on one or more projects and be selective about what is committed:

Alternate Take 1: Check-out each project as a separate working copy
  1. Create a new empty Application with no projects
  2. Use the SVN Navigator to select the root node of one of your projects in the repository
  3. Check this project out of the repository
  4. For the check-out destination, select the root folder of your newly created application
  5. You will get a warning on the Confirm Check Out dialog that you have selected a directory that is not empty - this is OK
  6. Continue to check out projects under your application root folder

  7. Now you can use JDeveloper's Commit Working Copy command on any node in a specific project and that project's changes will be committed.
Alternate Take 2: Filter the Outgoing Pending Changes Window

Using JDeveloper 11g you can filter the Pending Changes window by application or project. In the screen shot below I've filtered my outgoing changes to myProject1. I can select one or more of these files and with the context menu Commit Working Copy or Commit. I'd choose to select all the files and Commit if I had checked out my Application as the working copy. I'd choose Commit Working Copy if I had used Alternate Take1 to check out each project as a working copy. Unfortunately JDEV 10g doesn't have this filtering ability so this is an 11g only Alternate Take





I'm sure there are other Alternate Takes to both the level at which you version your code and how you manage checkin/out. I'd love to hear the good practices and the pitfalls.

2 comments:

John Stegeman said...

Hi Susan,

I strongly agree with your original take - versioning at the application level - the reason that versioning at the project level would not work for me is that there are dependencies among the projects (at least in the projects I work on) that would break the application if I only committed a project at a time. The obvious example - ADF Business Components in one project and the UI (ADF Faces with binding) in another. If I were to make a change such as adding an attribute to a view object and then adding it to a JSPX page - to me, that is a single development activity, and should be committed as a single change; in such a simple case, our bug tracking/enhancement tracking system would likely have a single ticket for such a request. Single change = single commit. It is obvious that if I committed one project at a time in that case, I've just broken the build.

However, I do understand that not everyone uses ADF BC/ADF Faces broken apart into projects this way, but I do - thus, versioning at the application level is the proper way for me.

Best regards

Susan said...

Hi John,

Application level versioning is my preference too. But I do have customers who (even using BC) prefer the project approach. For instance, I have one customer who wants to provide EO/VO centrally in a project that teams develop UI on top of in their own applications. But rather than using the library approach wants developers to be able to checkout and see the BC project. I'm working through this scenario at the moment.