ClearCase wants to merge unchanged files after deliver to alternate target - clearcase

Using Rational ClearCase v. 7.0.1.1 with UCM, I have a problem here when using ClearCase's "Deliver from Stream to Alternate Target" functionality.
Imagine we have one project integration stream and two developer streams A and B derived from it. Now I change a file in stream A. I want the delevoper owning stream B to be able to use my work without me having to deliver the file to the integration stream yet, so I deliver from stream A to the alternate target stream B.
So far, so good. I go on making another change to the file but the stream B developer does not need this change, so I don't deliver it to him.
After some more time, I deliver my work to the main integration stream. This works fine, although I wonder why ClearCase marks the merge as a normal "Merged" instead of "Merged (trivial)" - no one except me has made changes to the file.
After the delivery, a new baseline is created on the main integration stream.
The real problem arises when developer B tries to rebase his stream. Since developer B has never made any changes to the file, I'd expect the merge to be a trivial one with no interaction necessary. But what happens is that developer B is forced to resolve a merge conflict on that file graphically, letting him choose between the base version on the integration stream, the version I delivered to him and the version that I delivered to the integration stream.
The confusion goes on when after resolving the merge and completing the rebase, developer B wants to perform a delivery to the main integration stream. Apart from the activity that I originally delivered to him, he is also offered to deliver an activity that is named rebase_..., which I would never expect to be offered for delivery.
Am I missing something here? Are we using ClearCase incorrectly or is this a known limitation / bug? Has anyone experience with this functionality?
Thanks in advance for your help!
Jan

Actually, when I look at the version tree, the source of the conflict during the rebase is clear:
When you re-read the way ClearCase 3-way merge works, you see it needs to go back in the version tree in order to find a common ancestor to:
the source (Int/2)
the destination (B/1)
That common ancestor is Int/1
Now it is possible that a common line has changed between those two version since:
the source of the last rebase (Int/2) comes from A/3
the destination of the last rebase (B/1) comes from A/2
the common ancestor (Int/1) comes from A/1
If a common line has been modified (from A/1) both in A/2 and A/3... there is a reason for a manual merge resolution right there!
(I am testing this right now)
Got it! Conflict achieved!
Continuing on my previous experiment:
Let's make a new modif in Stream A:
M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo modif by A to B>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_a\adev\test>type aFile.txt
first line done on Int
Second line from Int
Addition by A to be delivered to B first
Modification by A to be delivered to Int, B does not need it
modif by A to B
Delivering that directly to B:
M:\vonc_test_dat_a\adev\test>ct deliver -to vonc_test_dat_b -target Test_DAT_B#\myPVob -cact -gmerge -force
Changes to be DELIVERED to non-default target stream in current project "Test_DeliverToAlternateTarget":
FROM: stream "Test_DAT_A"
TO: stream "Test_DAT_B"
Using target view: "vonc_test_dat_b".
Activities included in this operation:
activity:test_dat_a#\myPVob vonc "test_dat_a"
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\Test_DAT_A\2".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\Test_DAT_A\3" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -target Test_DAT_B#\myPVob -cact -complete -force
(Trivial merge)
Now let's COMPLETELTY CHANGE the content of that file:
M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo change first line>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_a\adev\test>type aFile.txt
change first line
And delivering to Int, with a new baseline put right after the deliver:
M:\vonc_test_dat_a\adev\test>ct deliver -force
M:\vonc_test_dat_a\adev\test>ct deliver -force -complete
M:\vonc_test_dat_a\adev\test>ct mkbl -comp ADV_TST#\myPVob -view vonc_test_dat_int TST_DAT1.2.0
(another trivial merge)
What about a rebase from B?
M:\vonc_test_dat_b\adev\test>ct rebase -bas TST_DAT1.2.0
Advancing to baseline "TST_DAT1.2.0" of component "ADV_TST"
Updating rebase view's config spec...
Creating integration activity...
Setting integration activity...
Merging files...
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\3".
Attached activity:
activity:rebase.Test_DAT_B.20090707.163300#\myPVob "rebase Test_DAT_B on 07/07/09 4:33:00 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\4 base \main\T
est_DAT_Int\3]
********************************
<<< file 1: M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\3
>>> file 2: M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\4
>>> file 3: M:\vonc_test_dat_b\adev\test\aFile.txt
********************************
---------[changed 1-4 file 1]----------|---------[changed to 1 file 2]---------
first line done on Int | change first line
Second line from Int |-
Addition by A to be delivered to B fir+|
Modification by A to be delivered to I+|
-|
*** Automatic: Applying CHANGE from file 2 [line 1]
============
============
-----------[after 4 file 1]------------|----------[inserted 5 file 3]----------
-| modif by A to B
|-
Do you want the INSERTION made in file 3? [yes] no
============
============
Output of merge is in "M:\vonc_test_dat_b\adev\test\aFile.txt".
Recorded merge of "M:\vonc_test_dat_b\adev\test\aFile.txt".
Build and test are necessary to ensure that any merges and configuration changes were completed correctly.
When build and test are confirmed, run "cleartool rebase -complete".
There you have it: a nice conflict between two incompatible changes from the common ancestor.
Here is the picture to illustrate that:
.

I am surprised by this conflict: since ClearCase does register the merge from Stream A to B, unless Stream B does not have the same foundation baseline (starting point for the branch, or initial label) than Stream A.
Apart from the activity that I originally delivered to him, he is also offered to deliver an activity that is named rebase_..., which I would never expect to be offered for delivery.
When you rebase from Int to B, you create an automatic "timeline" which links all the activities together.
Meaning, during the next deliver, B will have to deliver rebase even though no merge will be performed for all versions present in this changeset.
A few comments first:
you may want to avoid creating streams attached to resources (developer "A", developer "B"): if they are working on separate set of files for the same global "development effort", there should be only one Stream_FeatureF representing the task at hand.
A and B should then see the same LATEST of the same branch attached to that stream (no need to deliver from one stream to another)
If B constantly breaks A's work, then and only then a sub-stream can be created for the disruptive sub-feature which cannot be developed at the same time than the main Feature "F".
The deliver/rebase GUI does not display "Yes (trivial)" when a merge is trivial (see my test below). That does not mean the merge is not trivial (meaning that the base is the same than the source or the destination, see core concepts)
my test below respects the workflow of merges you describe, but shows only trivial merges.
What could explain non-trivial ones would be "evil twins" (a file added in one stream, but re-created from scratch in the other, with the same name)
All right, let's test this, assuming a Vob "adev" (stands for "development architecture", where my team stores its tools), with an UCM component ADV_TST in \adev\test.
ClearCase7.0.1 on Windows (although the Vob is actually on Unix)
Let's begin with a Test project, one Integration stream and one empty test component:
M:\>ct mkproj -in folder:ADV_Tests#\myPVob Test_DeliverToAlternateTarget#\myPVob
M:\>ct mkstream -int -in Test_DeliverToAlternateTarget#\myPVob Test_DAT_Int#\myPVob
Created stream "Test_DAT_Int".
M:\>ct mkview -tag vonc_test_dat_int -stream Test_DAT_Int#\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct rebase -bas ADV_TST0.0.0
Adding baseline "ADV_TST0.0.0" of new component "ADV_TST"
M:\vonc_test_dat_int\adev\test>ct rebase -complete
Let's make the component writable:
M:\vonc_test_dat_int\adev\test>ct chproj -amodcomp component:ADV_TST#\myPVob Test_DeliverToAlternateTarget#\myPVob
M:\vonc_test_dat_int\adev\test>ct chstream -generate Test_DAT_Int#\myPVob
M:\vonc_test_dat_int\adev\test>ct setcs -stream
A will create a file on Int, add it, modify it, and then put a baseline:
M:\vonc_test_dat_int\adev\test>ct mkact test_dat_int
M:\vonc_test_dat_int\adev\test>echo first line done on Int>aFile.txt
M:\vonc_test_dat_int\adev\test>ct co -nc .
M:\vonc_test_dat_int\adev\test>ct mkelem -nc aFile.txt
M:\vonc_test_dat_int\adev\test>ct ci -nc .
M:\vonc_test_dat_int\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_int\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_int\adev\test>echo Second line from Int>>aFile.txt
M:\vonc_test_dat_int\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_int\adev\test>type aFile.txt
first line done on Intct mkview vonc_
Second line from Int
M:\vonc_test_dat_int\adev\test>ct mkbl -comp ADV_TST#\myPVob TST_DAT1.0.0
Created baseline "TST_DAT1.0.0" in component "ADV_TST".
Now, let's create two sub-stream, one for each developers (may be considered "bad practice" though), both initialized with the same baseline TST_DAT1.0.0:
M:\vonc_test_dat_int\adev\test>ct mkstream -in Test_DAT_Int#\myPVob Test_DAT_A#\myPVob
M:\vonc_test_dat_int\adev\test>ct mkstream -in Test_DAT_Int#\myPVob Test_DAT_B#\myPVob
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_a -stream Test_DAT_A#\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct mkview -tag vonc_test_dat_b -stream Test_DAT_B#\myPVob -stg hostname_ccstg_c_views
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_a -bas TST_DAT1.0.0
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_a -complete
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_b -bas TST_DAT1.0.0
M:\vonc_test_dat_int\adev\test>ct rebase -view vonc_test_dat_b -complete
A will make a modification on his stream A, to be delivered to B:
M:\vonc_test_dat_a\adev\test>ct mkact test_dat_a
M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
Created branch "Test_DAT_A" from "aFile.txt" version "\main\Test_DAT_Int\2".
M:\vonc_test_dat_a\adev\test>echo Addition by A to be delivered to B first>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt
Delivering directly from stream A to B:
M:\vonc_test_dat_a\adev\test>ct deliver -to vonc_test_dat_b -target Test_DAT_B#\myPVob -cact -gmerge
Changes to be DELIVERED to non-default target stream in current project "Test_DeliverToAlternateTarget":
FROM: stream "Test_DAT_A"
TO: stream "Test_DAT_B"
Using target view: "vonc_test_dat_b".
Activities included in this operation:
activity:test_dat_a#\myPVob vonc "test_dat_a"
Created branch "Test_DAT_B" from "M:\vonc_test_dat_b\adev\test\aFile.txt" version "\main\Test_DAT_Int\2".
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\0".
Attached activity:
activity:deliver.Test_DAT_A.20090707.123738#\myPVob "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_A\1 b
ase \main\Test_DAT_Int\2]
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\
2".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\Test_DAT_A\1" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -target Test_DAT_B#\myPVob -force -complete
I confirm the GUI did not display Trivial although the textual output of the same deliver does mention Trivial merge...
A goes on working on 'aFile.txt' and delivers it to Int:
M:\vonc_test_dat_a\adev\test>ct co -nc aFile.txt
M:\vonc_test_dat_a\adev\test>echo Modification by A to be delivered to Int, B does not need it>>aFile.txt
M:\vonc_test_dat_a\adev\test>ct ci -nc aFile.txt
M:\vonc_test_dat_a\adev\test>ct deliver
Changes to be DELIVERED to default target stream in project "Test_DeliverToAlternateTarget":
FROM: stream "Test_DAT_A"
TO: stream "Test_DAT_Int"
Using target view: "vonc_test_dat_int".
Activities included in this operation:
activity:test_dat_a#\myPVob vonc "test_dat_a"
Do you wish to continue with this deliver operation? [no] yes
Checked out "M:\vonc_test_dat_int\adev\test\aFile.txt" from version "\main\Test_DAT_Int\2".
Attached activity:
activity:deliver.Test_DAT_A.20090707.124108#\myPVob "deliver Test_DAT_A on 07/07/09 12:41:08 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test\aFile.txt" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_A\2 base \main
\Test_DAT_Int\2]
Trivial merge: "M:\vonc_test_dat_int\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_int\adev\test\aFile.txt##\main\Test_DAT_
Int\2".
Copying "M:\vonc_test_dat_int\adev\test\aFile.txt##\main\Test_DAT_Int\Test_DAT_A\2" to output file.
Deliver has merged
M:\vonc_test_dat_a\adev\test>ct deliver -force -complete
(Another trivial merge)
Let's put a baseline on Int:
M:\vonc_test_dat_a\adev\test>ct mkbl -nc -view vonc_test_dat_int TST_DAT1.1.0
Created baseline "TST_DAT1.1.0" in component "ADV_TST".
Begin incrementally labeling baseline "TST_DAT1.1.0".
Done incrementally labeling baseline "TST_DAT1.1.0".
Now, we switch to B, who begins with a little work of his own on another file:
M:\vonc_test_dat_b\adev\test>ct mkact test_dat_b
M:\vonc_test_dat_b\adev\test>echo myFile by B>aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct co -nc .
M:\vonc_test_dat_b\adev\test>ct mkelem -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc .
And then, suddenly, he has to rebase his work with what has been consolidated in Int:
M:\vonc_test_dat_b\adev\test>ct rebase -bas TST_DAT1.1.0
Advancing to baseline "TST_DAT1.1.0" of component "ADV_TST"
Updating rebase view's config spec...
Creating integration activity...
Setting integration activity...
Merging files...
Checked out "M:\vonc_test_dat_b\adev\test\aFile.txt" from version "\main\Test_DAT_Int\Test_DAT_B\1".
Attached activity:
activity:rebase.Test_DAT_B.20090707.125044#\myPVob "rebase Test_DAT_B on 07/07/09 12:50:44 PM."
Needs Merge "M:\vonc_test_dat_b\adev\test\aFile.txt" [to \main\Test_DAT_Int\Test_DAT_B\CHECKEDOUT from \main\Test_DAT_Int\3 base \main\T
est_DAT_Int\Test_DAT_A\1]
Trivial merge: "M:\vonc_test_dat_b\adev\test\aFile.txt" is same as base "M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\
Test_DAT_A\1".
Copying "M:\vonc_test_dat_b\adev\test\aFile.txt##\main\Test_DAT_Int\3" to output file.
Output of merge is in "M:\vonc_test_dat_b\adev\test\aFile.txt".
Recorded merge of "M:\vonc_test_dat_b\adev\test\aFile.txt".
M:\vonc_test_dat_b\adev\test>type aFile.txt
first line done on Int
Second line from Int
Addition by A to be delivered to B first
Modification by A to be delivered to Int, B does not need it
M:\vonc_test_dat_b\adev\test>ct rebase -complete
No conflicts at all: Trivial merges again.
B goes on working on his file:
M:\vonc_test_dat_b\adev\test>ct setact test_dat_b
M:\vonc_test_dat_b\adev\test>ct co -nc aFileByB.txt
M:\vonc_test_dat_b\adev\test>echo a modif by B to be delivered to Int>>aFileByB.txt
M:\vonc_test_dat_b\adev\test>ct ci -nc aFileByB.txt
And then he delivers the all work to Int:
M:\vonc_test_dat_b\adev\test>ct deliver -cact
cleartool: Error: Activity "deliver.Test_DAT_A.20090707.123738" must be added to activity list to preserve baseline order in stream.
cleartool: Error: Activity "rebase.Test_DAT_B.20090707.125044" must be added to activity list to preserve baseline order in stream.
cleartool: Error: The list of activities specified is incomplete.
cleartool: Error: Unable to deliver selected activities.
cleartool: Error: Unable to deliver stream "Test_DAT_B".
I do confirm he has to select all activities (not just his): the timeline set during the last rebase has linked all activities together.
Even though no merge will be done with Activity "deliver.Test_DAT_A.20090707.123738" and Activity "rebase.Test_DAT_B.20090707.125044", they have to be included:
M:\vonc_test_dat_b\adev\test>ct deliver
Changes to be DELIVERED to default target stream in project "Test_DeliverToAlternateTarget":
FROM: stream "Test_DAT_B"
TO: stream "Test_DAT_Int"
Using target view: "vonc_test_dat_int".
Activities included in this operation:
activity:deliver.Test_DAT_A.20090707.123738#\myPVob vonc "deliver Test_DAT_A on 07/07/09 12:37:38 PM."
activity:test_dat_b#\myPVob vonc "test_dat_b"
activity:rebase.Test_DAT_B.20090707.125044#\myPVob vonc "rebase Test_DAT_B on 07/07/09 12:50:44 PM."
Do you wish to continue with this deliver operation? [no]
Attached activity:
activity:deliver.Test_DAT_B.20090707.131614#\myPVob "deliver Test_DAT_B on 07/07/09 1:16:14 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_Int\Test_DAT_B\1 base \main\Test_DAT_
Int\1]
********************************
<<< directory 1: M:\vonc_test_dat_int\adev\test##\main\Test_DAT_Int\1
>>> directory 2: M:\vonc_test_dat_int\adev\test##\main\Test_DAT_Int\Test_DAT_B\1
>>> directory 3: M:\vonc_test_dat_int\adev\test
********************************
-----------[ directory 1 ]-------------|---------[ added directory 2 ]---------
-| aFileByB.txt --07-07T12:50 vonc
*** Automatic: Applying ADDITION from directory 2
Recorded merge of "M:\vonc_test_dat_int\adev\test".
Created branch "Test_DAT_Int" from "M:\vonc_test_dat_int\adev\test\aFileByB.txt" version "\main\0".
Checked out "M:\vonc_test_dat_int\adev\test\aFileByB.txt" from version "\main\Test_DAT_Int\0".
Attached activity:
activity:deliver.Test_DAT_B.20090707.131614#\myPVob "deliver Test_DAT_B on 07/07/09 1:16:14 PM."
Needs Merge "M:\vonc_test_dat_int\adev\test\aFileByB.txt" [to \main\Test_DAT_Int\CHECKEDOUT from \main\Test_DAT_B\2 base \main\0]
Trivial merge: "M:\vonc_test_dat_int\adev\test\aFileByB.txt" is same as base "M:\vonc_test_dat_int\adev\test\aFileByB.txt##\main\0".
Copying "M:\vonc_test_dat_int\adev\test\aFileByB.txt##\main\Test_DAT_B\2" to output file.
Deliver has merged
M:\vonc_test_dat_b\adev\test>ct deliver -complete
.

Related

Checked out but removed error while merging activities

I wish to merge an activity with my activity, the former activity has new directories and new elements.
I am getting the following error on issuing a merge with the following command
ct findmerge activityname#/vob/** -fcsets -nc -merge
The errors are as follows in 2 cases
Case1: No new elements created directly the merge command
Errors
/vob/**/Build.mk [checkedout but removed]
/vob/**/file1 [checkedout but removed]
/vob/**/file2 [checkedout but removed]
/vob/**/file3 [checkedout but but removed]
cleartool: Error: Checked out version, but could not copy data to "/vob/siren/oam/sdh/pkg/Build.mk" in view: Permission denied.
Correct the condition, then uncheckout and re-checkout the element.
Case2: I created the elements and the directory structure still the same error
Note: There are no errors for the elements which already exist in the vob
Try again your findmerge activity (as described here), but this time, without using cleartool setview (meaning without using a path starting with /vob, the mounting point for the dynamic view set by cleartool setview).
Always use the full path of the destination dynamic view (the one where the merge occur): as I told you in your previous question, cleartool setview is nothing but trouble.
Use:
cd /view/yourDestinationView/vobs/siren
ct findmerge activityname#/vob/** -fcsets -nc -merge

ClearCase UCM: Branch created of file that is not part of an activity. What happened?

I have somehow created a branch of a file in clearcase UCM that is not part of an activity. I have no idea how to reproduce this, but my stream is showing many files with this symptom. How can I find these files, remove them, and prevent it from happening again in the future?
Here is an example of one such file, names redacted to protect the innocent:
xxxxxxxxxxx.cpp##/main/xxx-integration/xxxxxx-xxxxxxxx/0 Rule: .../xxx-xxxxxxx/LATEST
A ct lsact -long | grep <filename> returns no results.
Update:
I used a find command to track down all the files that are on the branch given (and redacted) above, though I still do not understand the issue.
Per VonC's answer, where is what I ended up doing:
cleartool find . -type f -version "version(.../xxx/LATEST)&&version(.../xxx/0)" -print | tee ~/tmp/files2
I then read through the list of files generated to make sure they made sense, then I verified they were not attached to an activity and removed the versions:
cat ~/tmp/files2 | while read
do
if [ -z "$(ct describe -fmt "%[activity]p" $REPLY)" ]
then
ct rmbranch -f ${REPLY%/0}
fi
done
That can happen ig those file were checkout in a base ClearCase view, ie a non-UCM view, withg a simple config spec:
element * .../xxx-integration/LATEST -mkbranch xxxxxx-xxxxxxxx
You can use a find command similar to "How can I find all elements on a branch with version LATEST that has no label applied?".
The difference is: for each version found, you need to describe it in order to check if there is an activity attached to it or not (with a fmt_ccase):
cleartool describe -fmt "%[activity]p" "$CLEARCASE_XPN"

Clearcase CASE INSENSITIVITY

I am trying to write a windows batch file to automate the checkout/check-in process for the ClearCasr tool but facing an issue with Case letters of the file name.
For example: if filename is "Hello_Working.txt" when I copied to my vob its becoming "hello_working.txt".
So when I do a checkout/check-in its prompting error as "Pathname not found".
I know MVFS "Clear Preserve" will solve the problem but if we change the setting other vobs which are running will affect, My admin suggested that your batch file script commands has to negotiate the cases of the file name. I am writing the command as below
Checkout:
ct co -nc H:\test1_view\test1_vob\Hello_working.txt
ct co -cfile "Comment"
Checkin:
ct ci -nc H:\test1_view\test1_vob\Hello_working.txt
ct ci -cfile "Comment"
Please let me know what needs to modify in the commands?
First, you don't have to co/ci -nc, and then co/ci -cfile "comment".
You can checkout with comment, and then ci -nc: a checkin without comment will use by default the comment given in the checkout step.
ct co -c "Comment" H:\test1_view\test1_vob\Hello_working.txt
ct ci -nc H:\test1_view\test1_vob\Hello_working.txt
Second, you can try checkin all the checked-out files, as in "Recursive checkin using Clearcase", which would make ClearCase find the right name (even when the filename is converted to lowercase in Windows dynamic view).
ct lsco -r -cvi -fmt "ci -nc \"%n\"\n" | ct
Even for one file, try the command ct lsco (cleartool lscheckout) in order to ask ClearCase for the right name.

Baseline creation interrupted

I tried to create a baseline today and ClearCase Explorer crashed (seemed to be after it was finished, but evidently it wasn't.)
I tried to recreate the baseline and it gives me an error saying there are some that are "in_progress" so it can not proceed.
I removed the baseline, and I am trying to remove the "in_progress" label types.
When I remove the lbtype, it says that a directory is locked.
I did an lslock -all and removed the locks on a project and a baseline and now there is nothing listed when I do an lslock -all.
I tried to remove the "in_progress" lbtype and it is still saying that something is locked. Is there another way to find out what is preventing it from working?
I know this may be confusing, so if any clarification is needed, I am willing to update my question.
"ct lslock -all"
--09-09T09:47 USER lock project "XXXXXXX" (locked)
"Locked for all users. Project locked for future changes as released."
--09-20T09:56 USER lock baseline "XXXXXXXXX" (locked)
"Locked for all users."
(removed locks)
"ct lslock -all" shows nothing
"rmtype -rmall lbtype:BASELINE_in_progress#\VOB
There are 1228 labels of type "BASELINE_in_progress".
Remove labels? [no] yes
cleartool: Error: Lock (obsolete) on directory element prevents
operation "remove label".
cleartool: Error: Unable to remove label type "BASELINE_in_progress".
The actual error message is
possible stranded temporary lbtype name found: "`abaselinexxx.yyyy_in_progress`".
The idea is to:
remove all the _inprogress types in the vob(s) involved by the UCM components
$ ct rmtype -rmall lbtype:abaselinexxx.yyyy_in_progress#\\avob
There are 1690 labels of type "abaselinexxx.yyyy_in_progress".
Remove labels? [no] yes
promote the baseline into a fully labelled one:
ct chbl -full -nc baseline:abaselinexxx.yyyy#\apvob
The locks which could prevent those operations to complete are:
on the lbtype
on the vob (ie the vob itself could be locked)
on the pvob (the pvob or one of its admin pvob could be locked)
Few remarks, from the comments:
cleartool lslock -all won't display obsolete files ("obsolete" being one form of locking): cleartool lslock -all -obsolete will.
to unlock a set of locked files, you have a choice between for and cleartool find -exec commands.
Windows
for /f "delims==" %x in ('cleartool lslock -all -obsolete -fmt "%Xn\n"') do cleartool unlock "%x"
Unix, in view context...
cleartool lslock -all -obsolete -fmt "%Xn\n" | xargs -i{}
cleartool unlock %x
Note that a cleartool find would unlock everything under a certain path.
If you know that path (and all -- or most of all -- its content) is locked, then it can work:
ct find /path/to/a/locked/directory -exec '/usr/atria/bin/cleartool unlock "$CLEARCASE_PN"'

How to delete the specific version of a file from clearcase

On clearcase machine, Let say i have a file called xyz.c.
I have checked out the file using command
jco -nc xyz.c
now i did some changes and checked-in the file(not submitted yet) using below command
jci -nc xyz.c
I have now a new version created for the file xyz.c, which we can see by below command
jlog xyz.c
---------------------------------------------------------------------------
Date: 04-May-11.13:05:02 User: abc
Event: create version
Version: xyz.c##/main/1
Comment:
---------------------------------------------------------------------------
Date: 28-Apr-11.12:19:51 User: abc
Event: create version
Version: xyz.c##/main/0
Comment:
---------------------------------------------------------------------------
Date: 28-Apr-11.12:19:51 User: abc
Event: create branch
Version: io.c
Comment:
---------------------------------------------------------------------------
Let say i have again checked out for my coding purpose and checked in again
which created version 2.
My question is : if i am on version 2, How can i delete the version 2 so that i can get my version 1. Note : version 2 is checked in but not submitted yet.
If you have checked in version 2 and:
don't have set any label on it
don't have create new other version on it
you could do a cleartool rmver xyz.c##/main/2, but that is quite dangerous and not recommended.
A revert (as I wrote here) would be:
cleartool merge -graphical -to xyz.c -delete -version \main\2
Another (less complex) option would be to hijacking the content of xyz.c with version 1, that is just replace the local copy (you would need then to checkout and checkin in order to create a version 3.
See SO answer on cleartool get:
cleartool get –to xyz.c xyz.c##\main\2
Your question is not very clear in terms, whether you have already checked in version 2 or not. In case you have not checked in version 2, you have to uncheckout the file. If you have checked in the file, you will need a rollback
My question is : if i am on version 2,
How can i delete the version 2 so that
i can get my version 1.
I do not think you do not have to delete it as such, my interpretation is that you just want to see the older version 1 at some point after version 2 is created, is that right?
All versions of the content of the file (e.g. versions /main/0, /main/1 and /main/2) are stored in the VOB. However, when you work with clearcase you are not accessing the VOB directly, you are working with a view and all file access goes through the view server. The config specification will determine what versions of a file your view will select.
So if you specifically want to see version 1 of the file you can add
element xyz.c /main/1
to the config_spec before the rule that would otherwise select a version (use cleartool ls -l to check).
Also I notice you use commands jco, jci and jlog which is not the same as the standard clearcase commands cleartool co, cleartool ci and cleartool lshistory. So it seems like you are using some additional interface layer, there might be some issues with this.
You can also just bring up the version tree on the file graphically and right-click on the latest version and select delete.

Resources