Evil Clones - The SCM nightmare that can stop you in your tracks

It can happen to anyone. First the feeling of disbelief, then the cold sweat; you try pinching yourself, hoping it's some bad dream and you'll wake up and they'll be gone . . .

There, that's my catchy first line of my first novel written, now just the other 150 pages to invent. But unfortunately it really can happen to you - if you are working with ClearCase you may have come across evil twins. But I want to talk about a different nightmare that can occur if you are using SVN or CVS.

Here's the scenario. You and a team member are both working on a file (let's call it MyClass1) checked out of SVN.







Your colleague, as part of her edits, renames MyClass1 to CloneClass1 and commits the working copy.







SVN uses copy/delete commands for a rename:
First MyClass1 is copied (so that the history is maintained) to CloneClass1.
Then MyClass1 is deleted from the repository.
The screenshot of the SVN repository (left) shows the new resulting file with CloneClass1.

CVS is not quite so clever is uses add/delete: It adds CloneClass1 and deletes MyClass1 - so none of the history of MyClass1 is copied to the new CloneClass1.

But back to the SVN example. You have edited the checked out MyClass1 and are oblivious to your team member's edits. Not a problem, you might think as an update from the repository would absorb the changes or at the very least show you a conflict over the rename. Unfortunately not!

Here is where the nightmare that I'm calling Evil Clones appears.

The repository rightly updates your working copy with CloneClass1. But wait, your class MyClass1 is not only still in your App Navigator, but is no longer under version control!







If you think about it, this is correct -

• SVN has replaced MyClass1 with CloneClass1. It has no recollection of the object MyClass1 so there is no merge of MyClass1 and CloneClass1.
• You wouldn't want to lose the additional changes you have made to MyClass1 in your working copy - and it is not under version control - well, it's not, because it doesn't exist in the SVN repository
• You can easily recognize that MyClass1 has been replaced by CloneClass1 so it's a simple job to move your changes to CloneClass1 - or is it. . .

This is expected behavior from Subversion and it seems that they recognize it as a bug . The example above is very simple. But what when you have 00s of different files in your working copy?

I'd be interested in how you work around this shortcoming in SVN. Here are some of my thoughts:

• Don't rename, if you think you must, think again!
• If you must, then refactoring or plain renaming of files (this is not specifically a Java problem, could be XML metadata, diagram or any other file type) should always be taken seriously in team development. In our JDeveloper development teams it's usual for the developer thinking about renames to email colleagues, check for dependencies and most definitely comment both the code, the check-in and the build notes to minimize the possible problems.
• How renaming is handled in your team should be part of your defined development process. It should take account of your source code system, your build system and provide workarounds as necessary
• If you are using JDeveloper and find that one of your objects appears to 'lose' its versioning status after an update - think rename!
  
• Always ensure that you fully comment a rename on commit so that other users can use the log to find out where and why their object was deleted from the repository

In a forthcoming post I want to look more closely at how you detect and work to correct a rename problem. Specifically I want to use JDEV's offline database objects to do this. In the Java world developers may be more aware of the power of refactoring. But, as I said above, this is not a problem restricted to Java. I want to highlight the effect on XML and database objects.

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.