We have a patch model where we're intending on using cset.pl -findmerge <activity> to selectively merge cumulative activities to a patch stream (integration stream to integration stream). Note that we're using a single stream model; although support for teams working with their own dev stream would be supported (i.e. when they join a project they would be working with the integration by default).
However there's the issue of activity dependencies we're trying to solve.
So say you have integration stream A,
file a.txt
-> Change 1 (baselined ReleaseA)-> Change 2 -> Change 3
fileb.txt
-> Change 1 (baselined ReleaseA)-> Change 2
an integration stream B and the config. manager decides they want to include "Change 3" in a new patch (patch integration stream - integration stream C).
They perform a cset.pl fetchmerge against Change 3 (which includes changes for Change 2).
Change 2 for fileb does not get picked up so the issue is identifying these activity dependencies.
Anyone have any ideas?
If Change3 is a rebase/deliver activity you can use
%ct lsact -contrib Change3
to get a list of contributing activities
and then traverse any of the rebase/deliver activites listed as contributing
activities to trace if any of them has Change2 as the contributing activity.
Also assuming that the foundation baseline for the patch stream is the one used for RelaseA,shouldn't you need to list activities from Change1 onwards when you do the merge ?
i.e shouldn't your findmerge invocation be something like
%findmerge ... Change2,Change3 -fcsets ...
Note (in addition to sateesh's answer), a deliver -act Chaange3 (instead of a findmerge) would list Change2 and Change1 as activities to include in your deliver.
It would pick up on those dependent activities, probably following an algorithm close to the one described by sateesh.
See "About activity dependencies in the deliver operation"
alt text http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/deliver_depnd.gif
Had to use a variety of cctool commands to view current version in view and pushed it into a script to get a list of activity dependencies
Related
Is there any command which will display all the information associated with a particular activity branch. Like:
On which label it was created?
On which label currently it is?
What are the files are checked in the branch. What are there latest versions?
Who created this branch?
Is there any single command for all those which will display these information (not in graphical view)
The only two commands are:
cleartool lsact
cleartool descr -l activity:anActivity#/apvob
You can get that way the list of versions for each file.
See also "Cleartool command to list all files part of a changeset"
You can combine the second command (descr) with a -fmt (fmt_ccase) directive in order to get other activity attributes, like its associated view (from which you can deduce the stream)
But that won't give you from which label the activity started. For that, you can list the foundation baseline of the stream.
And that won't give you "On which label currently it is?": the activity list versions. The fact that those versions are or are not labelled is not relevant for the activity. You would need to describe the version in order to see if it has a label attached to it.
If this is UCM, and by "activity branch" you mean the stream it is on, you can get the information about the stream by using cleartool lsstream -long -cview while in the view in question. The output will look something like this:
stream "brian_testrep1_2"
2017-08-17T17:50:15-04:00 by Brian.None#DESKTOP-LQ0QA86
owner: DESKTOP-LQ0QA86\Brian
group: DESKTOP-LQ0QA86\None
project: testrep1#\testproject (development stream)
default deliver stream: testrep1_Int#\testproject
development streams:
contains activities:
foundation baselines:
test_2#\testproject (testcomp1#\testproject) (modifiable)
recommended baselines:
views:
Brian_testrep1_2
policies:
...
In ClearCase GUI, when I tried to check-in, an empty comment field will be shown, which I can fill in check-in messages.
Is it possible to set template for this message?
For example, when the team need to checkin, below message will be shown, and each team member can just fill in the commit message.
Reviewer:
Test suggestion:
Thanks
There is no native template mechanism that I know of.
You can try and see if the ClearCase environment variables could help, like setting in a pre-op checkin trigger a:
CLEARCASE_CMNT_PN
The path name of the file in which cleartool and multitool cache the most recent user-supplied comment. Defining or removing this EV enables or disables comment caching.
(and make sure that file contains a message template)
That thread from 2005 though mentions:
The CLEARCASE_* environment variables are effectively read only (changes to them have no effect.)
Some potential options are:
A) reject comments that do not meet your template and make the user fix them and redo the checkin/out
B) put a wrapper around checkout/in operations to meet your template needs
C) use 'ct chevent' to change the comment during a postop trigger
D) use attributes, hlinks, or labels to store the information instead of using the comment field. (You can apply the attributes, hlinks, or labels during the preop)
I'm thinking that C or D might be your better choices.
Is it possible in clearcase to checkout a file for modification such that it is impossible to check it back in? I’m going to be hacking some files on a private branch, only some of which I want to ever check in. I want to eliminate the possibility of accidentally checking in unwanted changes. (I know we can write a trigger to check for magic keywords in the checkout comment; I'm look for something built-in to CC.)
"Hacking some files" is spelled in ClearCase lingo: hijacked files in a snapshot view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a snapshot view
change the read/write right (at the OS level, nothing to do with ClearCase here)
modify them directly (without checkout them first, hence the "hijacked" state)
The OP Kevin Little adds in the comment:
Alas, we only use dynamic views
Easy enough:
"Hacking some files" is also spelled in ClearCase lingo: eclipsed files in a dynamic view.
All you have to do is to:
lock those files (except for the few developers you know are likely to checkout/checkin the files: cleartool lock -nusers userA,userB,... aFile)
create a dynamic view
copy the files you need to modify as aFile.tmp
modify the config spec to not select them
copy them back to their original name (they became "eclipsed" as their private version override their official versioned counterpart)
remove the "none" selection rules from the config spec
modify them directly
To not select them, add to the config spec (ct edcs) before the other rules:
element /a/path/to/aFile1 -none
element /a/path/to/aFile2 -none
...
To restore them, all you have to do is move or remove those files.
They will be dynamically be replaced by their original and still versioned element.
I don't know about the administration. From a user standpoint, you could have 2 views. In one view, checkout the files you don't want to check in. In the other view (your view), check them out unreserved. Then, if you try to check them in, you'll get an error because they're checked out to the other view.
I'm using CC project explorer and when I right-click the stream I don't have possibility to choose the baseline. If I try to change the baseline on already existing snapshot CC says that I can't rebase on a baseline created in the same stream.
If I try to change the baseline on already existing snapshot CC says that I can't rebase on a baseline created in the some stream.
That is normal. It means some work (checkouts/checkins) have been done since the choice of the foundation baseline.
If you need to see (as in "just look, read-only access"), you can create another project with just one stream. On that empty stream, you will be able to select whatever baseline you need (as long as the associated component is non-modifiable, you will also be able to change that baseline).
Then you create your snapshot view referencing that new "consultation" stream.
The bottom line is that you cannot consult old baselines of a component on a stream where that same component is modifiable (and has been modified)
Another way to quickly consult the content of a Baseline is:
through dynamic view (because you skip the "update" -- loading of files -- entirely
more specifically a base dynamic view -- which does not reference any UCM stream.
in this dynamic view, you simply add a selection rule on your config spec:
element * MY_BASELINE_X.Y.Z
And here you go: instant access.
You will not be able to do any checkouts because ClearCase will detect those files are part of a UCM component.
But you will be able to:
explorer the files
edit the config spec and replace the baseline by any other baselines.
2 warnings:
use the complete name of the baseline, not its title
mount the correct vob (in a dynamic view, if no vob is mounted, you will not see one file!)
I have been taught that when you create an activity based baseline the selected activities are baselined and the newest version of all the other files in the vob are baselined. When I baselined the other day I found that this did not happen. Two files had version 2 baselined again, not version 3. Versions 2 and 3 are different.
To create the baseline I use a similar command as:
mkbl -c "This is my comment" -activities Activity#/vobs/46002913/46002913_pvob
-full -view 46002913_ucmview_int BaselineId
Is what I was taught wrong or am I using a malformed command?
One scenario explaining this would be the versions 3 were not visible in the view used to make said baseline.
As mentioned in the mkbl man page:
Before creating the baseline, be sure that the label is unlocked and ordinary (not global) and that labeled elements are checked in. Once the baseline is created, the label cannot be moved or removed except by privileged users.
Be certain the label selects some version of all visible elements.
Either the versions 3 were created just after the baseline (their date can be compared to the one of the baseline), maybe because they were checked-out (in some other view or even in 46002913_ucmview_int view), and checked-in later.
Or they were not visible for some reason (custom config spec)