Running CC 8.0.0.3 w/UCM and ClearQuest enabled.
We have a build system which is supposed to run mkbl -view after a successful build in the integration stream. Normally this completes in a few seconds after each build. That works fine, but it turns out one build job omitted the mkbl command.
I am trying to retroactively apply the mkbl command for those. I need to do this 4x to come up to date.
BL label - #activities - # element versions
1.2.6 - 57 - 513
1.2.7 - 16 - 107
1.3.0 - 26 - 159
1.4.0 - 60 - 460
I have attempted the command:
cleartool mkbl -view my_view -act ${ACT_LIST} -inc -c "${LABEL}" ${LABEL}
where ACT_LIST is the list of activities (activity#/mypvob), since the prior baseline, LABEL is my label
It's been running over 12 hours and still has not even come back indicating creating baseline.
Am I doing this wrong? Is it just slow? Is it possible to retroactively apply a baseline?
Thanks.
First, it would be quicker for your first non-missing baseline is promoted to "full" instead of incremental: the delta (of files or activities) between two baselines would be quicker to compute.
You can keep creating incremental baselines on top of that full one.
Then you can start testing making a baseline with just one activity and see if that complete: making multiple baselines with the same label will lead to multiple baselines with different ID (same title).
Is it possible to retroactively apply a baseline?
Baselines are created sequentially on the stream: they cannot be "inserted".
If you already started to put new baselines on that stream (after missing a couple), you cannot try and create ones before.
But the OP mentions:
No, there were no subsequent baselines and the first baseline's list of activities goes back to the last actual baseline.
Since mkbl fails (too long), I would:
change the config spec of the UCM view in order to select files before a certain date (add a time-based selection rule at the start of its config spec)
put a label on all files of the component (mklbtype+mklabel)
import that non-UCM label as a baseline (mkbl -import)
See if you can create your baselines that way.
The OP Ian W concludes in the comments:
neither incremental nor full worked.
I tried mkbl -import, but then I could not recommend and use as a future baseline, so I gave up.
I had the 4 baseline equivalents all labelled, then made a full of the latest, which worked and should keep me moving forward
Related
Can someone guide me to deal with this in the right and best way? I have two active dev branches where-in the same code base is being modified and one integration branch in a base clearcase environment. But i wanted to prevent code promotion from branch 2 to integration branch and allow merge only from branch 1 to integration branch. Please advise.
If there are different users delivering from dev streams to integration streams, you could (using cleartool lock -nusers ... stream:aStream#\vobs\apvob):
lock devstream1 for all except dev1 (that way you are sure dev1 can only work on devstream1),
lock devstream2 for all except dev2 (that way you are sure dev2 can only work on devstream2),
lock intstream for all except you and dev1 (that way only dev1 can deliver to intstream)
What if I or dev1 mistakenly promoted code from devstream2 to intstream
Then you would need a preop deliver_start trigger (with mktrtype).
That trigger would control the OIDs of the streams in the trigger since these are immutable: cleartool describe -fmt %On <stream-name>
If one of them is the one for devstream2, the trigger would exit in error, denying the deliver.
Since it sounds like your using Base ClearCase, you can use a preop 'checkin' trigger. The script the trigger executes would look to see if the checked out version about to be checked in has any incoming Merge hyperlink(s). If it does, the script can verify that the "from" end of the hyperlink is coming from branch1 and exit with a 0 status if so. If it's coming from any other branch, the script will print a descriptive error message and exit with a non-zero status (thus preventing the checkin).
When creating the trigger type, you can limit the scope of the trigger to the integration branch (which I'll call 'my_int_branch' in the example below) which helps with performance. The command line might look something like this:
% cleartool mktrtype -element -all -preop checkin -brtype my_int_branch -exec path_to_allow_branch1_merge_script allow_branch1_merge
In the script, you can get the Merge hyperlink(s) attached to the checked out version with something like:
cleartool describe -fmt '%[hlink:Merge]p\n' $CLEARCASE_PN
If there are any incoming Merge hyperlinks, you'll get one line per hyperlink looking something like this:
"Merge#2877#/vobs/myvob" <- "/vobs/myvob/mydir/file.c##/main/branch1/3"
The script then just has to verify that the outer branch of the "from" version is "branch1".
I need to retrieve the list of changes or activity in same branch for different component(or Project group). Say I am committing the changes for two components ABC & xyz in same branch. And whenever I create build I apply the label abc.00.date & xyz.00.date respectively. Now major CQ's are of abc so whenever I make build for xyz and apply lable, label attach to abc chnages and when I compare the baseline with comapre tool, it shows the chnages of abc project also.
My requirement is to get the changes between label of xyz.00.date group ONLY as there is numerous lables of two groups in same branch.
I need to retrieve the list of changes or activity in same branch for different component
The main command remains cleartool lsactivity, as illustrated here:
foreach act ( `cleartool lsact -in astream#/vobs/avob` )
set changeset = `cleartool lsact -fmt "%[versions]p" $act`
echo $changeset | tr ' ' '\n' >> $tmpoutput
end
For the difference between baselines, use cleartool diffbl, as in "Why does Clearcase diffbl include activities from my development stream when I diff integration stream baselines?"
cleartool diffbl -nmerge -act bl1 bl2
That will give you a list of activities that you can feed to the foreach loop above, modified as:
foreach act ( `cleartool diffbl -nmerge -act bl1 bl2` )
On Windows, those unix commands are available with the installation of Gnu On Windows: uncompress, and add GoW\bin to your %PATH%.
In a major development, I have added multiple files to the source control into my private branch. There were also existing files that was modified and checked into my private branch. Now as we are approaching to merge the changes to our project branch, I would like to validate all the elements I have newly added to my private branch, to ascertain if the locations are correct (ex, they should have been placed in another location and a symlink should have been added)
I listed all the elements in my private branch, but could not figure out, which of these elements were newly added.
Is there a reliable way to do so?
You can do a query finding all elements in a given branch since a certain date for a certain user:
cleartool find . -type f -branch "brtype(abranch)" -element "{created_since(10-Jan)}" -user aloginname -print
(this would search only files, as mentioned in "how to find files in a given branch", and also in "how can I list a certain user's activity in a branch")
The other approach is to create a dedicated (simple base ClearCase) view to display those elements, as in "Get all versions from a specific time" or in "how to find out all the activities happend in a branch in the last month?".
But generally, the first query is enough.
Is there a way I can create a view that will give me a snapshot of all the files modified in a specific ClearCase branch?
For example, say I have two branches:
product_1.0_dev
product_migration_1.0_dev
The second branch is conceived as a testing ground for upgrading our core framework dependencies. I know that if I modify a file in product_migration_1.0_dev, then I will have a \1 version under this branch, so there has to be a way to write a load rule to get this info easily into a snapshot.
Any ideas?
That would be a selection rule (not a load rule)
element * .../product_migration_1.0_dev/LATEST
element * .../product_1.0_dev/LATEST
element * /main/LATEST
Note the '...' notation (see version selector), an ellipsis wildcard which allows to select a branch at any branch level.
Note that would list all files, including the ones you want.
If you want to see only the files for a particular branch, you still need to select their parent directories: and those might not have a version in the product_migration_1.0_dev branch.
So the following config spec (that I invite you to test in a dynamic view first: it is quicker, then you will report that config spec in a snapshot view, with its own load rules) would be more precise:
element * .../product_migration_1.0_dev/LATEST
element -directory * .../product_1.0_dev/LATEST
element -directory * /main/LATEST
So you would select files and directories having a LATEST in product_migration_1.0_dev branch.
Otherwise, you select directories only in product_1.0_dev branch or in main branch.
That way, you are sure to select the parent directory of an element which might have a version in product_migration_1.0_dev branch.
If you don't do that, your view won't ever be able to select the files, because their parent directories are not accessible (none of their versions is selected from which a product_migration_1.0_dev branch starts).
Can we get the list of baselines of a project in clearcase within in a certain time period, say, last 6 months.
The cleartool lsbl command usually lists baselines:
per streams
from the oldest to the most recent
If you can restrict your search to one stream (ct lsbl -stream ...), you need to list everything and then filter the result.
You can use the fmt option to display only the name of the baseline and its date.
cleartool lsbl -fmt "%d %n\" -stream...
You would get results like:
2007-01-10T12:41:45+01:00 MYBL_20070110.1263
2007-01-25T16:33:13+01:00 MYBL_20070125.3901
2007-01-26T12:25:23+01:00 MYBL_20070126.7020
2007-01-31T12:21:44+01:00 MYBL_20070131.7277
2007-02-01T16:54:21+01:00 MYBL_20070201.7671
From there, you can filter and/or sort the results.