Rebase Cannot be Cancelled

A developer got some problem with a rebase operation. After messing around, she ended up manually checked in all the versions in the rebase change set, only to find out later that the rebase could not be cancelled nor resumed. Okay, it was time to call ClearCase admin for help.

$ cleartool rebase -status -stream RP_WT_VER5.10@/vobs/Horizon_PVOB
cleartool: Error: The ClearCase version used to start the rebase operation in progress does not match the current version.
cleartool: Error: Unable to restore operation.
cleartool: Error: Unable to restore from pvar.

The activity contains an empty change set. But it cannot be removed.
$ cleartool rmact rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB
Remove activity "activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB"? [no] y
cleartool: Error: Activity "activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB" is set in view "".
cleartool: Error: Unable to remove activity rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB.

C:\Li\tmp>cleartool setact -view RP_WT_VER5.10_DDV -none
cleartool: Error: View "RP_WT_VER5.10_DDV" is set activity to activity"rebase.RP_WT_VER5.10.20081022.172717" which is currently involved in anactive deliver or rebase operation. The set activity of this view may not bechanged until the operation has completed.
cleartool: Error: Unable to unset activity in view RP_WT_VER5.10_DDV.

$ cleartool dump stream:RP_WT_VER5.10@/vobs/Horizon_PVOB

RP_WT_VER5.10
oid=31df728b.324a44c0.a5b2.70:02:42:d0:06:dc dbid=74825 (0x12449)
mtype=activity name="RP_WT_VER5.10" type=85
usid=UNIX:UID-9150 gsid=UNIX:GID-8025
...
work items:
user=106 view=ff390327.2f8d4680.83d0.ac:04:d8:db:0a:08
user=106 view=65e7f7b0.fb494922.88bf.18:08:1c:40:01:26
user=106 view=cddce13f.ac9d41cf.acb4.0d:cd:f0:f5:e1:93
user=106 view=5ef30ee5.538b462b.9fa1.b7:6a:4f:41:5c:eb
user=106 view=8ebe7608.b1214e8f.9039.07:18:5c:ba:26:3e
user=106 view=e1e56bc4.5942465f.81a5.f5:80:cd:d0:74:51
user=106 view=5d0175d3.1c984f7e.940c.8a:49:cc:18:c4:21
Process variables:
name=SUM_CSPEC_ID value=0:5
name=UCM_STREAM_RECBLS value=oid:c328a47b.c0694013.b050.70:ec:52:d0:57:7a@vobuuid:fc0b3963.655011dc.84f7.00:01:83:31:69:b5oid:9c091eb4.c51b4791.a11a.a2:7e:5b:5b:ba:b8@vobuuid:fc0b3963.655011dc.84f7.00:01:83:31:69:b5oid:3546cb0f.09254d4f.bf59.0d:b7:cb:41:78:39@vobuuid:fc0b3963.655011dc.84f7.00:01:83:31:69:b5oid:42fc12cb.d1cf4666.9670.48:f1:02:dd:15:5b@vobuuid:fc0b3963.655011dc.84f7.00:01:83:31:69:b5
name=UCM_REBASE value=ver=3
owner=dantchev
start=1224710837
act=oid:e1d5538e.b9224182.913d.d7:93:21:a0:b0:4c@vobuuid:fc0b3963.655011dc.84f7.00:01:83:31:69:b5
view=ff390327.2f8d4680.83d0.ac:04:d8:db:0a:08
state=reprocess_merging
csid=kind:UCM.Stream
...

$ /opt/rational/clearcase/etc/utils/ucmutil
ucmutil> setpvar -pvar UCM_REBASE -none stream:RP_WT_VER5.10@/vobs/Horizon_PVOB
You are about to modify internal data. Any mistake will damage the objects.
Do you want to continue? [no] y
Set UCM_REBASE = "" [cleared]

The rebase operation is cancelled and the stream is back to normal.
C:\Li\tmp>cleartool rebase -status -stream RP_WT_VER5.10@\Horizon_PVOB
No rebase in progress for stream "RP_WT_VER5.10".

But the activity is still at a intermediate status. It cannot be unset nor deleted.
% cleartool rmact rebase.RP_WT_VER5.10.20081022.17271
Remove activity "activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB"? [no] y
cleartool: Error: Activity "activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB" is set in view "".
cleartool: Error: Unable to remove activity rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB.

C:\Li\tmp>cleartool setact -view RP_WT_VER5.10_DDV -none
cleartool: Error: View "RP_WT_VER5.10_DDV" is set activity to activity
"rebase.RP_WT_VER5.10.20081022.172717" which is currently involved in an
active deliver or rebase operation. The set activity of this view may not be
changed until the operation has completed.
cleartool: Error: Unable to unset activity in view RP_WT_VER5.10_DDV.

One more variable to go.
% cleartool dump activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB

rebase.RP_WT_VER5.10.20081022.172717
oid=e1d5538e.b9224182.913d.d7:93:21:a0:b0:4c dbid=88924 (0x15b5c)
mtype=activity name="rebase.RP_WT_VER5.10.20081022.172717" type=73
usid=UNIX:UID-9150 gsid=UNIX:GID-8025
master replica dbid=3
title="rebase RP_WT_VER5.10 on 10/22/2008 05:27:17 PM."
process definition uuid=fc0b3a7f.655011dc.84f7.00:01:83:31:69:b5
state dbid=64
role dbid=52
user dbids: 105
view=""
planned effort=0.00
actual start=10/22/08 17:22:21
priority=50
dtsm=1224710541
mod count=0
flags=0x4, Setwork
parent dbid=74832
work items:
user=105 view=ff390327.2f8d4680.83d0.ac:04:d8:db:0a:08
Process variables:
name=UCM_INTEGRATION_ACTIVITY value=ver=1
state=1

ucmutil> setpvar -pvar UCM_INTEGRATION_ACTIVITY -none activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB
You are about to modify internal data. Any mistake will damage the objects.
Do you want to continue? [no] y
Set UCM_INTEGRATION_ACTIVITY = "" [cleared]

C:\Li\tmp>cleartool setact -view RP_WT_VER5.10_DDV -none
Cleared current activity from view RP_WT_VER5.10_DDV.

% cleartool rmact rebase.RP_WT_VER5.10.20081022.172717
Remove activity "activity:rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB"? [no] y
Removed activity "rebase.RP_WT_VER5.10.20081022.172717@/vobs/Horizon_PVOB".

Everything is back to normal.

Baseline vs. Label

When comparing elements or versions in UCM, many people use baseline the same way as label in Base ClearCase. For example, to find out all elements changed between two version, use the command:

cleartool find -all -element '{lbtype_sub($LABEL1) && lbtype_sub($LABEL2)}' -version '{(lbtype($LABEL1) && ! lbtype($LABEL2)) || (lbtype($LABEL2) && !lbtype($LABEL1))}' -print

Full baseline name can be used to substitute the LABEL1 and LABEL2 variable in the command in UCM.


However, baselines are different from labels. A full baseline labels every elements in the stream, no matter they are visible or not; while label only applies to visible elements selected by the view. This implies that you cannot use two baseline names to find out which elements have been deleted (renamed) between two baselines. The following command will fail to give out the removed files.

cleartool find . -element 'lbtype_sub($BASELINE1) && !lbtype_sub($BASELINE2)' -print

If you have labeled every elements selected by the two baselines respectively, you can get deleted files by command:

cleartool find . -element 'lbtype_sub($LABEL1) && !lbtype_sub($LABEL2)' -print

Strangled Deliver

A Developer started a deliver after he had moved around some files. The deliver got stuck at deliver_complete. The following is the error message (when I resumed the operation at the command line).

cleartool: Warning: 4 elements were skipped because they are not visible. You should determine why they are not visible before you complete this deliver or rebase operation. If these elements should be visible, cancel this operation, fix the problem, and re-run the operation.

cleartool: Error: Unable to access "C:\view_stg\CBFE14.8_SwipeDevice_Integration\FrontEnd\CBFE-FE\JavaSource\com\cibc\bankframe\fe@@\main\Mainline_i\NL72_CBFE14.8_SwipeDevice\1\messaging": No such file or directory.

cleartool: Error: Unable to checkin "C:\view_stg\CBFE14.8_SwipeDevice_Integration\FrontEnd\CBFE-FE\JavaSource\com\cibc\bankframe\fe@@\main\Mainline_i\NL72_CBFE14.8_SwipeDevice\1\messaging".

cleartool: Error: Unable to checkin versions in activity "deliver.WenAndy_CBFE14.8_SD.20080729.164552".

cleartool: Error: Unable to perform checkin.

cleartool: Error: Unable to complete integration.

Unable to complete deliver.

After failed to cancel or complete the activity, I tried to bring back the problematic folder to the target view with no succeed. I tried to remove the target view hoping to clear all its reference. That did not help. I decided to remove the deliver activity.

c:\> cleartool describe -long activity:deliver.streamxxxxx
...
change set versions:
...

Remove all the change set in the activity:
c:\> cleartool rmver -xhlink xxxx

Remove the activity:
c:\> cleartool rmact deliver.streamxxxxx

After that the deliver activity was no longer seen from CC project explorer. But the following command showed that the deliver activity was still recorded somewhere.

M:\qinl_CBFE14.8_int>cleartool deliver -stream WenAndy_CBFE14.8_SD@\CBFEProjects -status
cleartool: Warning: Unable to construct object "oid:191965f1.df304728.b92a.74:92:09:52:a9:39@vobuuid:4597339c.992b11dc.8f55.00:01:83:31:69:b5".
cleartool: Error: Unable to find view by uuid:25b3dbb0.f3be43ca.b8b5.54:36:84:ad:6b:98, last known at "unknown:unknown".
cleartool: Error: Unable to get view handle.
cleartool: Warning: Unable to construct object "25b3dbb0.f3be43ca.b8b5.54:36:84:ad:6b:98".
Deliver operation in progress on stream "stream:WenAndy_CBFE14.8_SD@\CBFEProjects"
Started by "WenAndy" on "2008-07-29T16:45:52-04"
The integration activity has not been created.
The target view has not been specified.
Activities will be delivered to the default target stream "stream:CBFE14.8_SwipeDevice@\CBFEProjects" in project "project:CBFE14.8@\CBFEProjects".

Baselines to be delivered:
baseline:deliverbl.WenAndy_CBFE14.8_SD.20080729.164552@\CBFEProjectscomponent:FrontEnd@\CBFEProjects
Activities included in this operation:
activity:Merge_Two_Projects_To_One@\CBFEProjects

C:\Li\tmp>cleartool dump stream:WenAndy_CBFE14.8_SD@\CBFEProjects

WenAndy_CBFE14.8_SD
oid=a5be5398.d6754080.8af6.d2:06:5d:22:7f:fd dbid=874 (0x80eb66)
mtype=activity name="WenAndy_CBFE14.8_SD" type=85
usid=NT:S-1-5-21-1481920619-292190258-1324514410-329804 gsid=NT:S-1-5-21-148192
0619-292190258-1324514410-201237
master replica dbid=3
title=""
process definition uuid=f90e2e65.3f9b11dc.905f.00:01:83:f9:3b:ad
state dbid=64
role dbid=52
user dbids: 106
config spec:
ucm
identity UCM.Stream oid:a5be5398.d6754080.8af6.d2:06:5d:22:7f:fd@vobuuid:f6ae2d0
d.3f9b11dc.905f.00:01:83:f9:3b:ad 1

# ONLY EDIT THIS CONFIG SPEC IN THE INDICATED "CUSTOM" AREAS
#
# This config spec was automatically generated by the UCM stream
# "WenAndy_CBFE14.8_SD" at 2008-07-30T16:57:24-04.
#
....
end ucm

#UCMCustomElemBegin - DO NOT REMOVE - ADD CUSTOM ELEMENT RULES AFTER THIS LINE
#UCMCustomElemEnd - DO NOT REMOVE - END CUSTOM ELEMENT RULES

# Non-included component backstop rule: no checkouts
element * /main/0 -ucm -nocheckout

#UCMCustomLoadBegin - DO NOT REMOVE - ADD CUSTOM LOAD RULES AFTER THIS LINE

view=""
planned effort=0.00
priority=50
dtsm=1193942176
mod count=0
flags=0x16, Children, Setwork, Isolated
parent dbid=616
child activities:
878 internal071101.144125
879 internal071101.144125.1
916 internal071114.094245
work items:
user=106 view=1d3877c5.88ab11dc.9a89.00:01:83:f9:3b:ad
user=106 view=e91938ef.c3d44a19.8149.45:2b:c5:1c:02:d1
Process variables:
name=SUM_CSPEC_ID value=0:1
name=UCM_DELIVER_INTEGRATION_VIEW value=bf4d6c88.394f4ea3.8a7b.33:90:71:d7:85:8b
name=UCM_DELIVER value=ver=3
owner=wenandy
start=1217451758
act=oid:bc09e55c.0a994ca8.8e3e.fe:09:77:c1:f1:03@vobuuid:f6ae2d0d.3f9b11dc.905f.
00:01:83:f9:3b:ad
view=bf4d6c88.394f4ea3.8a7b.33:90:71:d7:85:8b
state=merging
target_stream=oid:18ab7ae8.08f3476f.954b.ed:a5:cd:12:49:fd@vobuuid:f6ae2d0d.3f9b
11dc.905f.00:01:83:f9:3b:ad
bls=oid:14d26418.01234f34.971b.c5:86:a4:97:12:66@vobuuid:f6ae2d0d.3f9b11dc.905f.
00:01:83:f9:3b:ad
bls_created=oid:14d26418.01234f34.971b.c5:86:a4:97:12:66@vobuuid:f6ae2d0d.3f9b11
dc.905f.00:01:83:f9:3b:ad
optype=1
orig_replica=oid:f6ae2d11.3f9b11dc.905f.00:01:83:f9:3b:ad@vobuuid:f6ae2d0d.3f9b1
1dc.905f.00:01:83:f9:3b:ad

hyperlinks from object:
arrow=876
type=31
hlink vob=f6ae2d0d.3f9b11dc.905f.00:01:83:f9:3b:ad
hlink obj=d0c38394.85eb4f1e.a797.ff:64:cb:3d:1f:fb
from vob=f6ae2d0d.3f9b11dc.905f.00:01:83:f9:3b:ad
from obj=a5be5398.d6754080.8af6.d2:06:5d:22:7f:fd
to vob=f6ae2d0d.3f9b11dc.905f.00:01:83:f9:3b:ad
to obj=5d3c6ee9.27424740.a08a.77:87:09:90:62:b0
arrow=877
type=38
hlink vob=f6ae2d0d.3f9b11dc.905f.00:01:83:f9:3b:ad
hlink obj=1db21860.ef93482b.abd7.d2:8b:3d:9d:d2:ee
from vob=f6ae2d0d.3f9b11dc.905f.00:01:83:f9:3b:ad
from obj=a5be5398.d6754080.8af6.d2:06:5d:22:7f:fd
to vob=f6ae2d0d.3f9b11dc.905f.00:01:83:f9:3b:ad
to obj=4943b18d.833011dc.87f8.00:01:83:f9:3b:ad

With admin's privilege, run /opt/rational/clearcase/etc/utils/ucmutil to clean the UCM_DELIVER attribute of the source stream.

ucmutil> setpvar -pvar UCM_DELIVER -none stream:xxxx@/vobs/CBFEProjects
You are about to modify internal data. Any mistake will damage the objects.
Do you want to continue? [no] y
Set UCM_DELIVER = "" [cleared]

C:\Li\tmp>cleartool deliver -stream WenAndy_CBFE14.8_SD@\CBFEProjects -status
No deliver operation in progress on stream "WenAndy_CBFE14.8_SD".

Done.

hosts file ignore in Windows

Got a new Windows XP box at office. After I added a host-ip mapping in the c:\winnt\system32\drivers\etc\hosts file, I still could not ping to the host. It seemed that the hosts file was ignored.

Ping request could not find host dse-750-test1. Please check the name and tryagain.

I did some research in the internet. The most common solution is to ensure the following registry value is correct, as it may be altered by some software.

Key: HKLM\system\currentcontrolset\services\tcpip\paramters
Value: DataBasePath
Type:REG_EXPAND_SZ
Data:%SystemRoot%\system32\drivers\etc

Some also mention the ipconfig /flushdns command, and to restart the DNS client service.

Others use filemon and regmon tool to trace. They found the following error message:

OPEN C:\WINDOWS\system32\drivers\etc\hosts ACCESS DENIED NT AUTHORITY\NETWORK SERVICE

After added the user to the security tab (with READ ONLY access), it solved the problem.

However, none of them seems to work in my case.

Finally, I found the solution: rename the hosts file and create a new one; then restart the DNS Client Service. It worked. Modifying the hosts file and restart the service did not work, even a reboot did not.

tar copy Failed on NFS

To move VOB data from one server to another, we usually create a tar ball, ftp to the other server, and untar the file. This time, we wanted to try a "better" way.

We share the file system from the target and mount it from the source server. cd to the VOB storage directories, do the tar copy as a one line command as root.

tar cvf - . | (cd /mnt/ccstore/vobs; tar xvfP -)

Everything looked fine until ClearCase started. In the log file, it complained some file could not be found. It turned out that those zero-sized files were not copied over. We had to fix it by using the old way, tar cvf-> ftp -> tar xvf. Later experiment showed that the tar copy works well between local folders, not NFS.

ClearCase Server Migration

We moved our ClearCase to new server over the weekend, and copied the VOB to a new disk array. The VIP (scm0) of the server did not change. However, the server name changed from cbfe-dev-cm01 to clearcase1. We always use the VIP to access ClearCase. All the VOBs should be defined using the VIP.

After ClearCase was started, the cleartool desc command failed.

qinl@clearcase2% cleartool desc vob:/vobs/HealthCheck
versioned object base "/vobs/HealthCheck"
created 2005-08-11T11:04:35-04:00 by ClearCase Admin (ccadmin.clearcase_cbfe@cbfe-dev-cm01)
"Created by make_vob.pl script"
VOB family feature level: 4
VOB storage host:pathname "scm0:/ccstore/vobs/HealthCheck.vob"
VOB storage global pathname "/ccstore/vobs/HealthCheck.vob"
database schema version: 54
modification by remote privileged user: allowed
cleartool: Error: Problem starting vob_server for vob scm0:/ccstore/vobs/HealthCheck.vob
cleartool: Error: See albd or vob error logs on host scm0
Attributes:
FeatureLevel = 4
Hyperlinks:
AdminVOB -> vob:/vobs/CBFEProjects

$ tail albd_log
2008-03-28T10:50:31-04:00 albd_server(3711): Ok: Server vob_server(3938) exited
with status 1
2008-03-28T10:50:31-04:00 albd_server(3711): Error: Server vob_server (pid=3938)
on "/ccstore/vobs/HealthCheck.vob" died on startup; marking it as "down".

$ cat /var/adm/atria/vob_log
2008-03-28T11:26:06-04:00 vob_server(5831): Error: The vob_object registry for "/ccstore/vobs/HealthCheck.vob" specifies incorrect hostname for server; expected hostname: cbfe-dev-cm01 actual hostname: scm0. Use cleartool unregister/register -vob to correct.

$ cat /ccstore/vobs/HealthCheck.vob/.hostname
clearcase1


The information in the vob_log is good enough for a solution.

$ cleartool unreg -vob xxx
$ cleartool reg -vob -host scm0 -hpath /ccstore/vobs/HealthCheck.vob /ccstore/vobs/HealthCheck.vob

$ cat /ccstore/vobs/HealthCheck.vob/.hostname
scm0

Everthing was fine after re-registery the VOB.

CCRC deliver_complete Trigger

All the other triggers work well in our CCRC environment except one. Our deliver_complete trigger did not create the baseline and recommend it as expected.

# create the baseline
$cmd = "cleartool mkbl -c \"$dlvracts\" $basename";
`$cmd`;

# recommend the baseline
$cmd = "cleartool chstream -recommended $bl $stream";
`$cmd`;


The workaround is to create a dynamic view on RWP server and use the -view option in the mkbl command.

$cmd = "cleartool mkbl -c \"$dlvracts\" -view myViewTag $basename";

I hope IBM will fix this in the next release. Otherwise, we have to create a view for each stream for the deliver.

The print statement in the trigger script does not work well in CCRC environment. When debugging, it is better to write to a local file on the RWP server. And make sure that the file is accessible by the web account.

Analyze of VOB Size Report

From the chart in my previous blog, we can see that the size of one of the VOBs, FrontEnd, has increased sharply (by 250MB) over Feb 13. There are several reason could led to this. The most possible one is new code is being introduced into source control. A simple command can do this:

cleartool setview ccadmin_view
cd /vobs/FrontEnd
cleartool find -all -elem '{created_since(13-Feb-2008)}' -print

...

/vobs/FrontEnd/.@@/main/artemenk_CBFE15Pre/3/Framework/main/
artemenk_CBFE15Pre/8/wsee/main/artemenk_CBFE15Pre/1/api.jar@@

/vobs/FrontEnd/.@@/main/artemenk_CBFE15Pre/3/Framework/main/
artemenk_CBFE15Pre/8/wsee/main/artemenk_CBFE15Pre/1/com.bea.core.annogen_1.1.0.0.jar@@

/vobs/FrontEnd/.@@/main/artemenk_CBFE15Pre/3/Framework/main/
artemenk_CBFE15Pre/8/wsee/main/artemenk_CBFE15Pre/1/com.bea.core.antlr_2.7.7.jar@@

/vobs/FrontEnd/.@@/main/artemenk_CBFE15Pre/3/Framework/main/
artemenk_CBFE15Pre/8/wsee/main/artemenk_CBFE15Pre/1/com.bea.core.common.security.api_4.1.0.0.jar@@
...

After browsing through the result, we can conclude that a new directory with some large libraries have been newly added to ClearCase. And the increase of the VOB size is normal.

Monitoring VOB size

Another important item to monitor is the VOB size. VOB size can impact in a couple of ways.

For an individual VOB, its size should be increasing at a stable pace. If there is a dramatic increase, it often indicates problems.

For the total size of all VOBs, if its size grows too close to the size of the file system, new disks/hardwares should be configured to support the increase. On the other hand, as the total size of VOBs increase, the backup time for ClearCase also increases. Make sure that the backup window is large enough, and the backup device has enough capacity.

Monitoring ClearCase License Usage

One of the SCM daily tasks is to monitor the ClearCase license usage. I wrote a simple script to gather the data periodically and generate an excel chart as the report.

The recent reports showed that the license usage hit our max licenses on peak hours. It means that some developers would get a "no license" error when trying ClearCase operations. The reason is that the development team started a new project and many new hires started to join the team. Based on this, we purchased new licenses to accommodate more concurrent ClearCase access.

what has changed for a rebase?

Some new developers came to ask the question: "I did a rebase. But I could not see any rebase activities. Did the rebase successful? If so, what's changed after the rebase?"

These are valid questions. In fact, they are very good questions. Normally after a rebase, you will notice that there is a new activity with a title like "rebase ...". These activities contain the change set for the rebase operation. However, sometimes, the rebase operation does not generate the "rebase..." activity. That's when people come up with the questions.

A rebase operation changes the foundation baseline of the stream from the previous recommend baseline of the parent stream to the current one. If you do not change any file in the delta of the two baselines, i.e, you do not touch the same files as the recommended baseline, you will not get a rebase activity. However, your view will reflect the new version of the elements. When you check out the files in the future, they will be branched out from the new versions. If you have changed the files in the delta, ClearCase will do the merge for you, and you will see the rebase activity. From the version tree, a merge arrow will be drawn from the recommended version to your version.

Dynamic View == Always up-to-date?

You may think that a dynamic view of a stream will always reflect the LATEST version of elements in the stream. Well, you may be wrong.

If you find out that you are still looking at an older version in a view, while there are newer versions of the element in the stream, don't be surprise. This can happen. One possible reason is that the stream has more than one views. When you use one of the views to rebase the stream from its parent stream, the config spec (yes, a UCM view still has a config spec) has changed, while the other views still refer to the old foundation baseline.

....
element "[39730511c62311d9847000018376dd1b=\MidTier]/..." CBFE14.5_2008_01_14 -mkbranch CBFE14.5_LinkRemoval
....

To synchronize the view with the stream, you can click the "synchronize with stream" button in the view property page, or run "cleartool setcs -stream" in command line.

The ClearCase Eraser -- Versions Recorded in UCM Baseline

ClearCase UCM brings in more dependencies for the elements and ClearCase objects. It becomes harder to remove anything from ClearCase. Here in this blog shows how to remove a version that is "recorded in UCM baseline".

Before deleting the activity, we have to remove all the versions in the activity, -- if we do not want to move the versions to another activity.

$ cleartool lsact -l rebase.CBFE14.5_base.20071204.174114@/vobs/CBFEProjects
activity "rebase.CBFE14.5_base.20071204.174114"
04-Dec-07.17:39:26 by Qin (qinl.cbfedev@CBAD4-XCIDH3)
"Integration activity created by rebase on 12/4/2007 5:41:14 PM.
"
owner: qinl
group: cbfedev
stream: CBFE14.5_base.old@/vobs/CBFEProjects
title: rebase CBFE14.5_base on 12/4/2007 5:41:14 PM.
change set versions:
/vobs/MidTier/BaseUtil/src/com/cibc/evo/logging/CbfeDefaultLogger.java@@/main/Mainline_i/CBFE14.5_base/2
/vobs/MidTier/BaseUtil/src/.classpath@@/main/Mainline_i/CBFE14.5_i/CBFE14.5_base/2
/vobs/MidTier/BaseUtil/src/.project@@/main/Mainline_i/CBFE14.5_i/CBFE14.5_base/2

$ cleartool rmver -xbranch -xlabel -xattr -xhlink /vobs/MidTier/BaseUtil/src/com/cibc/evo/logging/CbfeDefaultLogger.java@@/main/Mainline_i/CBFE14.5_base/2
cleartool: Error: Cannot remove versions which are recorded in UCM baseline.
cleartool: Error: No versions of "/vobs/MidTier/BaseUtil/src/com/cibc/evo/logging/CbfeDefaultLogger.java" to remove.

$ cleartool lsbl -stream CBFE14.5_base.old@/vobs/CBFEProjects
04-Dec-07.13:23:05 CBFE14.5_2007_12_4.8538 HZ18 "CBFE14.5_2007_12_4"
stream: CBFE14.5_base.old@/vobs/CBFEProjects
component: MidTier@/vobs/CBFEProjects

$ cleartool rmbl CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects
Remove baseline "CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects"? [no] y
cleartool: Error: Cannot remove baseline that has been delivered.
cleartool: Error: Unable to remove baseline "CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects".

$ cleartool desc -l baseline:CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects
baseline "CBFE14.5_2007_12_4.8538"
created 04-Dec-07.13:23:05 by Zhao (HZ18.cbfedev@CBAD3-XCIDVQ)
"DOMDAM_base_class@\CBFEProjects"
owner: hz18
group: cbfedev
component: MidTier@/vobs/CBFEProjects
label status: Incrementally Labeled
change sets:
deliver.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects
promotion level: INITIAL
depends on:
Attributes:
PromotionLevel = "INITIAL"
Hyperlinks:
BaselineLbtype@13505@/vobs/CBFEProjects -> lbtype:CBFE14.5_2007_12_4.8538@/vobs/MidTier
Integrate@13511@/vobs/CBFEProjects -> anyactivity:timeline071202.075859@/vobs/CBFEProjects

$ cleartool rmhlink Integrate@13511@/vobs/CBFEProjects
cleartool: Warning: Hyperlinks of type "hltype:Integrate@/vobs/CBFEProjects" are used to implement UCM and should not be directly manipulated unless directed by customer support.
cleartool: Warning: Hyperlinks of type "hltype:Integrate@/vobs/CBFEProjects" are used to implement UCM and should not be directly manipulated unless directed by customer support.
Removed hyperlink "Integrate@13511@/vobs/CBFEProjects".

$ cleartool rmbl CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects
Remove baseline "CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects"? [no] y
cleartool: Warning: Searching PVOBs for baselines that depend upon baseline "CBFE14.5_2007_12_4.8538". This may take a few minutes...

Removed baseline "CBFE14.5_2007_12_4.8538@/vobs/CBFEProjects".

$ cleartool rmver -xbranch -xlabel -xattr -xhlink /vobs/MidTier/BaseUtil/src/com/cibc/evo/logging/CbfeDefaultLogger.java@@/main/Mainline_i/CBFE14.5_base/2
Removing these versions of "/vobs/MidTier/BaseUtil/src/com/cibc/evo/logging/CbfeDefaultLogger.java":
/main/Mainline_i/CBFE14.5_base/2 (has: hyperlinks)
Remove versions? [no] y
Removed versions of "/vobs/MidTier/BaseUtil/src/com/cibc/evo/logging/CbfeDefaultLogger.java".

$ cleartool rmact rebase.CBFE14.5_base.20071204.174114@/vobs/CBFEProjects
Remove activity "activity:rebase.CBFE14.5_base.20071204.174114@/vobs/CBFEProjects"? [no] y
Removed activity "rebase.CBFE14.5_base.20071204.174114@/vobs/CBFEProjects".

The ClearCase Eraser -- Delivered Baseline

Needless to say that, to remove a stream from ClearCase, the stream must be "clean", no views, no activities, no baselines, etc. In my previous blog, I have demonstrated how to remove an activity that has change set. Today, I am going to show you how to remove a baseline that has been delivered.

Try to remove a stream with baseline on it. Got errors.
$ cleartool rmstream CBFE14.5_base_hz18@/vobs/CBFEProjects
Remove stream "CBFE14.5_base_hz18@/vobs/CBFEProjects"? [no] y
cleartool: Error: Cannot remove stream that has baselines.
cleartool: Error: Unable to remove stream "CBFE14.5_base_hz18@/vobs/CBFEProjects".

Check which baselines are on the stream.
$ cleartool lsbl -stream CBFE14.5_base_hz18@/vobs/CBFEProjects
2007-12-04T13:22:38-05 deliverbl.CBFE14.5_base_hz18.20071204.132426 HZ18 "deliverbl.CBFE14.5_base_hz18.20071204.132426"
stream: CBFE14.5_base_hz18@/vobs/CBFEProjects
component: MidTier@/vobs/CBFEProjects

Try to remove the baseline. Got errors.
$ cleartool rmbl deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects
Remove baseline "deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects"? [no] y
cleartool: Error: Cannot remove baseline that has been delivered.
cleartool: Error: Unable to remove baseline "deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects".

$ cleartool desc -l baseline:deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects
baseline "deliverbl.CBFE14.5_base_hz18.20071204.132426"
created 2007-12-04T13:22:38-05 by Zhao (HZ18.cbfedev@CBAD3-XCIDVQ)
"Baseline created by deliver on 12/4/2007 1:24:26 PM.
"
owner: hz18
group: cbfedev
stream: CBFE14.5_base_hz18@/vobs/CBFEProjects
component: MidTier@/vobs/CBFEProjects
label status: Not Labeled
change sets:
promotion level: INITIAL
depends on:
Attributes:
PromotionLevel = "INITIAL"
Hyperlinks:
Integrate@13500@/vobs/CBFEProjects -> anyactivity:timeline071204.132453@/vobs/CBFEProjects

The hyperlink looks suspecious.
$ cleartool rmhlink Integrate@13500@/vobs/CBFEProjects
cleartool: Warning: Hyperlinks of type "hltype:Integrate@/vobs/CBFEProjects" are used to implement UCM and should not be directly manipulated unless directed by customer support.
cleartool: Warning: Hyperlinks of type "hltype:Integrate@/vobs/CBFEProjects" are used to implement UCM and should not be directly manipulated unless directed by customer support.
Removed hyperlink "Integrate@13500@/vobs/CBFEProjects".

Oops, there is a warning message. However when you see the warning, it is already too late. The hyperlink removed. Now you can try to remove the baseline.
$ cleartool rmbl deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects
Remove baseline "deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects"? [no] y
cleartool: Warning: Searching PVOBs for baselines that depend upon baseline "deliverbl.CBFE14.5_base_hz18.20071204.132426". This may take a few minutes...

Removed baseline "deliverbl.CBFE14.5_base_hz18.20071204.132426@/vobs/CBFEProjects".

Now the stream is "clean" to be removed.
$ cleartool rmstream CBFE14.5_base_hz18@/vobs/CBFEProjects
Remove stream "CBFE14.5_base_hz18@/vobs/CBFEProjects"? [no] y
Removed stream "CBFE14.5_base_hz18@/vobs/CBFEProjects".

How to run mktrigger in post_mkstream trigger

As we know that mktrigger must be fired in a view context. However, sometimes we need to run mktrigger even though there is no view yet. For example, in my post_mkstream trigger, I want to attach a no_mkactivity trigger to the newly created stream.

cleartool mktrtype -ucm -postop mkstream -nc -execu "cleartool mktrigger no_mkactivity stream:\$CLEARCASE_STREAM" -execw "cleartool mktrigger no_mkactivity stream:%CLEARCASE_STREAM%" post_mkstream

However, when a developer joins the project to create his development stream my_dev_str, the post_mkstream trigger reports "unable to determine view for my_dev_str: no such file or direcotry". That's because he does not have any view yet. Even if he has a view, the view may not be started, or the current directory may not be under the view root.


Workaround.
Create a view that is available to everyone. Set to the view before call mktrigger in post_mkstream trigger.

cleartool mktrtype -ucm -postop mkstream -nc -execw "ccperl \\\\scm\\admin\\post_mkstream.pl" -execu "/ccstore/admin/post_mkstream_unix.pl" post_mkstream


A simplified version of the post_mkstream.pl script.

#!/usr/bin/perl

$stream = $ENV{"CLEARCASE_STREAM"};

$rst = `cleartool mount \\CBFEProjects`;
$rst = `cleartool startview ccadmin_view`;
chdir "m:\\ccadmin_view\\CBFEProjects";
$rst = `cleartool mktrigger no_mkactivity@\\CBFEProjects stream:$stream`;
$rst = `cleartool endview ccadmin_view`;
exit 0;

The ClearCase Eraser -- Activity

In ClearCase, it is not recommended to delete anything from the source control. And UCM makes it extremely hard to remove an UCM object once it is been modified.

The following steps guide you through to remove an activity with change set.

First get the list of versions in the change set.
$ cleartool lsact -l DOMDAM_base_class
activity "DOMDAM_base_class"
04-Dec-07.11:00:59 by Cheung (dc81.Domain Users@CBAD1-XCILPE)
owner: hz18
group: unknown
stream: CBFE14.5_base_hz18@/vobs/CBFEProjects
title: CBFE14.5: DOMDAM base class
change set versions:
/vobs/MidTier/Srv/src/com/cccc/evo/dom@@/main/Mainline_i/CBFE14.5_base_hz18/2
/vobs/MidTier/Srv/src/com/cccc/evo/dom@@/main/Mainline_i/CBFE14.5_base_hz18/2/AbstractQuery.java/main/CBFE14.5_base_hz18/1
/vobs/MidTier/Srv/src/com/cccc/evo/dom@@/main/Mainline_i/CBFE14.5_base_hz18/1
/vobs/MidTier/Srv/src/com/cccc/evo/dom@@/main/Mainline_i/CBFE14.5_base_hz18/1/Query.java/main/CBFE14.5_base_hz18/1
/vobs/MidTier/Srv/src/com/cccc/evo/dal/cache/CacheManagerImpl.java@@/main/CBFE14.5_base_hz18/2
/vobs/MidTier/Srv/src/com/cccc/evo/dal/cache/CacheManagerImpl.java@@/main/CBFE14.5_base_hz18/1
/vobs/CBFE-lib/non-cccc@@/main/Mainline_i/CBFE14.5_base_hz18/1/xmlbeans-2.2.0/main/CBFE14.5_base_hz18/1
/vobs/CBFE-lib/non-cccc@@/main/Mainline_i/CBFE14.5_base_hz18/1

For each version in the change set, do the following command with the options to remove it with its reference.
$ cleartool rmver -xbranch -xlabel -xattr -xhlink /vobs/MidTier/BaseUtil/src/.project@@/main/Mainline_i/CBFE14.5_i/CBFE14.5_base_hz18/1

During the rever operation, some elements may be moved t lost+found if it is no longer being referenced.
cleartool: Warning: Object "xmlbeans-2.2.0" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "xmlbeans-2.2.0.e650a507ad794c789fed652fcf875fcb".

After all the version removed, run lsact again. There may be new items listed in the change set.
$ cleartool lsact -l DOMDAM_base_class
activity "DOMDAM_base_class"
04-Dec-07.11:00:59 by Cheung (dc81.Domain Users@CBAD1-XCILPE)
owner: hz18
group: unknown
stream: CBFE14.5_base_hz18@/vobs/CBFEProjects
title: CBFE14.5: DOMDAM base class
change set versions:
/vobs/CBFE-lib/lost+found/xmlbeans-2.2.0.e650a507ad794c789fed652fcf875fcb@@/main/CBFE14.5_base_hz18/1

repeat the rmver and lsact until the change set is empty.

The activity can be removed now.
$ cleartool rmact -force "DOMDAM_base_class"
Removed activity "DOMDAM_base_class".

Follow up: new version, still blue screen

Our Trend version upgraded to 8.550.1001. And most of developers upgraded ClearCase client to 7.0.0.1.

No reported issue yet. Just mark the url for reference.
http://www-1.ibm.com/support/docview.wss?rs=984&context=SSSH27&dc=DB520&dc=DB560&uid=swg21289223&loc=en_US&cs=UTF-8&lang=en&rss=ct984rational

Trend® Micro Scan Engine 8.550.1001

ClearCase version:
	7.0, 7.0.0.1, 7.0.1, 2003.06.00, 2003.06.01, 2003.06.10, 2003.06.12, 2003.06.13, 2003.06.14, 2003.06.15, 2003.06.16

To resolve the issue:

1. Change the following registry key by adding the new value below:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TmPreFilter\Parameters
DWORD: DevObjStackCheck
Value: 1


2. Restart the machine.

RE:
http://doublepaddle.blogspot.com/2007/07/clearcase-check-out-from-dyn-view-leds.html

Follow up: "Permission denied" during merge

Surprisingly soon, I encountered the same situation when delivery between two streams. Same condition, same error message. I canceled the delivery and tried another approach.

This time, instead of merging the Srv directory using ccadmin account on UNIX, I renamed the src.jtest folder to src.ctest foler first before I started the merge again. Everything worked fine, no complain about the permision, no error message. The only window popped up was to manually merge the Srv directory.I think this is a bug of ClearCase when merging a directory with renamed elements.

"Permission denied" during merge

M:\qinl_CBFE14.2_i\MidTier>cleartool merge -to Srv -version \main\CBFE14.0_i\1 \main\CBFE14.2_i\LATEST
********************************
<<<>>> directory 2: M:\qinl_CBFE14.2_i\MidTier\Srv@@\main\CBFE14.0_i\1
>>> directory 3: M:\qinl_CBFE14.2_i\MidTier\Srv@@\main\CBFE14.2_i\0
>>> directory 4: Srv
********************************
-----------[ directory 1 ]-------------|---------[ added directory 2 ]---------
-| runEMMAServer\ --09-06T15:53 vs217
*** Automatic: Applying ADDITION from directory 2
-------[ renamed directory 1 ]---------|-------[ renamed to directory 2 ]------
src.jtest\ 2006-06-12 yw17 | src.ctest\ 2006-06-12 yw17
merge: Error: An unexpected error has occurred.
merge: Error: Unable to remove "c:\li\tmp\tmp15600": Permission denied.

When delivering, the GUI showed "unexpected error" and prevented the delivery from proceed. Try it command line, the error message provided more information, but not much meaningful. All the involved elements are belonging to the same group as the user IDs, which have 777 access to them.

The error message is reproducable using different user IDs (thus different views) and machines. But using the ccadmin account in a UNIX box, the merge can proceed.

Examining the Srv directory more closely, I found out that, in the source, the src.jtest folder was renamed to src.jtest folder, and a new src.jtest folder was added as a new element; while in the target, the src.jtest folder has not been renamed yet. I believe it is the evil twin that caused the issue.

May be I should try to rename the src.jtest to src.ctest in the target manually before the merge. However, I have worked around the issue using the ccadmin id. Maybe next time.