IdleSun's Weblog

October 18, 2009

What’s Very Dangerous

Filed under: Quote — idlesun @ 8:09 pm

“What’s very dangerous is to not evolve, not invent, not improve the customer experience…”

Jeff Bezos, CEO, Amazon

Hear yourself: What’s dangerous.

CCRC – where is the view information?

Filed under: Source Control — idlesun @ 7:43 pm

One of my colleagues at work had gotten hard disk booting failure. Luckily, the HDD was attached to other PC and readable. The issue was that there were CCRC views with checked out files. The files couldn’t be checked in or undone unless the views were properly recovered. However, when all the CCRC and CCRC views  were copied over to newly built PC, the views were not visible in CCRC. CCRC doesn’t recognize the local CCRC views folders even though everything was copied to the exact same location as before.

The key to resolving this issue is to find out where the view information is stored locally on PC. Not in Windows registry. Not in the CCRC program folder. It is in the ‘.ccase_wvreg‘ file in user home folder. Once you find and open it in a text editor, you will get pretty good idea.

For more detail on .ccase_wvreg file, see About the CCRC .ccase_wvreg file.


CCRC – How to fix “undo checkout” failure

Filed under: Source Control — idlesun @ 7:13 pm

As far as my experience is concerned, CCRC (ClearCase Remote Client) is not that stable on Windows (It was much more stable on Linux).
One of the problems I faced was the “undo checkout” failure with the “Unable to find checked out version” error. I guess it happened because of some network issue when I tried undo initially. Again, my guess is that undoing was done on server side but it was not reflected properly on my CCRC client.
This ghost checked-out file is a real problem because you can not update or check in anymore. Luckily, I could find a solution myself.

The solution that I found involves manual editing of “.copyarea.db” file in the directory where that checked-out file is. So do it at your own judgment and risk. Here is the procedure:

  1. Make “.copyarea.db” file writable and open it using a text edit of your choice.
  2. Find the line with the problematic file name and modify the number in the end of the line from ‘1’ to ‘0’.
  3. Save modified “.copyarea.db” file and change back it to ‘read-only’.
  4. Open CCRC and find that the file is not marked as ‘checked-out’ anymore. (It may be marked as ‘hijacked’ already. Then skip next step)
  5. Do “update resource” on the file. And find that file turns into ‘hijacked’ state.
  6. Do “undo hijack”. Once it is done with no problem, the file state is synched and good to go.

Blog at