Change Owner of a stream in Clearcase

In IBM Clearcase, we can change the owner of a stream using the protect command. The protect command can be used to change permissions and ownership of VOB objects.

Eg:

clearool protect -recurse -chown TESTUSER -chgrp TEST_GROUP //Vob_Path

Note the -recurse switch used to recursively protect all the elements within the VOB.

Official detailed technote can be found here.

Eclipsed files in Clearcase

In Clearcase, sometimes files are not visible because they get eclipsed. This is because another object of the same name is being currently selected by the view.

This usually happens when the dynamic view is unable to delete the local copy of the checked out file even after you check it in. This view-private file thereby eclipses the file and is not visible.

One of the reasons why Clearcase is unable to delete the local copy is because some other 3rd party tool is accessing and locking the file.

Eclipsed files are denoted by the half-moon symbol as shown below:

Image courtesy : IBM

A detailed official IBM technote can be read here. Here you can read about recreating the steps for creating the eclipsed file scenario.

Hijacked file in Clearcase

Developers and coders who have their codes under Clearcase version control, often come across the hijacked file scenario. The scenario arises with a snapshot view ONLY and never with a dynamic view.

If you try to modify a loaded file within the snapshot view, without checking it out, it results into the file getting hijacked.

Since the file is not checked out, there's nothing to checkin. So in order to merge your changes, you will have to first checkout the hijacked files and then checkin.

If you want, you can later undo the hijacked files.

Fixing the text_file_delta error in Clearcase

If for some reason you're unable to checkin a checked-out file and you see the text_file_delta error, then do the following.

Change the type manager of the file to compressed_file using the command chtype.

Eg:

If you get the text_file_delta error while checking in test.txt, then use the foll. command.

cleartool chtype compressed_file test.txt

Detailed technote can be read here.

Deliver & Rebase basics - Clearcase

In clearcase when you want to your changes on your stream (child stream) to be delivered (merged) to the another stream (usually parent stream), it is known as delivering. In other words, you typically deliver from your development stream to the main integration stream.

The rebase is exact opposite of delivering. It is used to move the changes from parent stream onto a child stream. Typically in a multi-member team, when you rebase a parent stream onto your own child stream, the recommended baselines act as the foundation for the project.

Recommend a Baseline in Clearcase

The concept of baselines is to make sure all team members are on the same page and all have the latest updated versions of the project code.

A recommended baseline is a set / collection of the versions of various components which are identified as stable.

In order to recommend a baseline in Clearcase from the command line, we have to use the chstream command in the following fashion.

cleartool chstream -recommend <baseline-name> <stream-selector>

More detailed information can be found at this IBM technote here.

Unlock Stream - Clearcase

In Clearcase in order to unlock a stream use the commnd as follows:

cleartool unlock <stream-selector>

Eg:

cleartool unlock stream:Testvob_stream@\Test_pvob 

Clearcase Scenario - Reserved Checkouts

While using the Clearcase tool, one might come across a scenario where you are unable to checkout a certain file/folder because some other user has performed a reserved checkout on it.

In a simple scenario, one can ask the other user to either undo the checkout or perform a check-in.

However in a slightly tricky scenario, what if the other user has left the company and his user id is no longer active / functional.

Then in that case check with the administrator. He usually has the rights to remove the views associated with the reserved checkout.

He would most likely identify the view name by finding checkouts. Once the view name is found, he would try to find the view's UUID

Eg : cleartool lsview -long viewname

The UUID is usually of the form dfaa0744.56c611d4.b0da.00:b0:d0:20:d5:9d

Once the UUID is found, one can completely remove the defunct view from the system using rmview.

Eg : cleartool rmview -r -uuid dfaa0744.56c611d4.b0da.00:b0:d0:20:d5:9d

Now since the view associated with the reserved checkout gets deleted, the issue gets solved and the user can smoothly checkout. Hurray!

Clearcase - Squid Patch Activity

In UCM enabled ClearCase, where companies use ClearQuest for bug tracking and is connected with ClearCase, we sometimes come across instances of corruption of the activity records.

Eg. of error :

Could not perform requested operation: a UCM/Clearquest data 
inconsistency may exist:
Clearquest "Defect" record "<record ID>" is linked to a UCM object that 
can not be found.

This usually happens if the link between the activity record id and database is broken (probably due to network failure).

In such a case we need to run the squid_patch utility located at CC_HOME\etc\utils to re-link the record.

Usage:

• Go to E:\Program Files\IBM\RationalSDLC\ClearCase\etc\utils   (Check relevant location of the utils folder as per your setup)

• Then run the squid_patch utility 

[ Eg: squid_patch.exe DBD -activity DBD001122334 ucm_vob_object "" ]

Please refer the foll. technote and article.