An unusual hour at work and the help of a heavy wallet...

Today, I ran across several disturbing usability issues using the version handling tool ClearCase. I was to deliver some bug fixes I've made in an older version of an application in a developer stream to a newer version of the application in another stream using the deliver to alternate stream operation in QlearCase. This is certainly a very valuable operation and since this was the first time for me doing so, I was full of steaming anticipation. I thought, "...just a few clicks and I am home free. No cut 'n paste the ol' fashion way. Hell No!"

I had three bugg fixes in the old version. I figured that I could select these three specific work orders, click on deliver to alternate stream and voilá: I'd get some nice merge code screen shoots in which I could select the code to deliver to the main integration stream in a simple way. I've seen and used the merge view in ClearCase before so I knew this would be a breeze.

First issue: ClearCase would not let me choose only the three work orders that contained my bug fixes. I had to pick all work orders, including some other irrelevant stuff that I didn't want to integrate to my main integration stream. Ok. Fine! I'll do so imagining some extra clicks here and there in the merge view.

Some ~250 click procedures later in the merge view, an increasing awareness arose that something was probably deadly wrong. I had been changing some Controls properties in my user interface which meant that many .resx files had been changed. Further more, I seem to have had my Visual Studio.NET project files checked out for either adding or deleting files. Ok, I'll take the pain I figured and continued to click away... All of such changes would be button number 3 anyway (see algorithm below).

Some ~350 click procedures later my brain, set to 'algorithm mode', started looking for a way of improving efficiency. I define the clicking procedure algorithm accordingly:

Step 1: Move the mouse to the "arrow" button.
Step 2: Click!
Step 3: Move you mouse to either button labeled "2" or button labeled "3". Decide this based upon the merge view. Mostly 3.
Step 4: Click!
Step 5: Goto step 1. :)

Anyone who has performed this algorithm a couple of hundred times knows that your arm gets tired from moving the mouse. It would be much nicer finding a keyboard shortcut for at least one of the clicks. And, voila! There it was: Alt + "Arrow right" for clicking the "arrow button". Now, most keyboard I know of, there is a certain distance between the 'Alt' key and the right arrow key approximately consisting of some 20 cm. If you don't play the piano or otherwise is skillful at playing the classical guitar, you will have to use two hands. It doesn't take an Einstein to figure out that my algorithm is worth crap with this approach. I still would have to move at least one hand back and forth. Issue #2 as you might guess.

Light bulb!!! Unfortunately it didn't come from me :o) but from a colleague of mine, Mattias Ask: "Put a heavy something on the Alt key." Tada! My heavy wallet finally found a superior purpose other than containing receipts and, thank good, heavy coins.

Damn! The speed is up! 400! 500! 600! 700! Heavens! Does it ever end? A growing suspicion in my mind tels me that it isn't and that I should chicken out and abort. Yes I'll do so! I dare no longer. Just think if something go wrong and I have to undo some 1000 click procedures manually in the code.... Oh, Abort, abort! --- Hey! Wait a second... There is no clear way of aborting this thing and perform a rollback operation. Guess what the third (!) issue is? :( Coming to some Rational sense, I realised there was never any risk of having to undo a thousand clicks manually. And I started to click away again.

Well, I did give up anyway. :o( Even though not so time consuming I never was much for repeating dull tasks. In the end I did find a way of aborting: just closing the merge views as they appeared finally led you to a button with some kind of abort labeling (forgot the exact name). Doing so makes it possible to continue at a later phase. Ok, so I tried that just to see if it was working. Sure enough it did. But ClearCase got confused with three of my remaining files and refused to accept my choices (button "3" off coarse). I guess that makes my fourth devastating issue. So in the end, after some perhaps 1000 click procedures, I ended up with a complete failure. Here we go: back to the good ol' cut 'n paste. Someone recalls my previous blog about technicians sometimes preferring to do things as done before?

I don't like this at all. It seems to me that this should be working, if doing it right. And the fact that it didn't bothers the hell out of me. The most important lesson would off course be to have only one bug fix as one work orders to deliver to an alternate stream. But since I always would have to do this merging graphically there is still one problem as I see it. The main stream containing the later version of the code has normally some continued developed code (that’s why it is the next version, ehh!). And if a delivery from the developer stream to the integration stream has to take place, there normally should be lots of differences between the two versions. In essence meaning many click procedures. I would very much like some ClearCase expert to give me some answer to this question and some advice of 'best practices'. Hello world! Is anyone reading?