I need to list all of the activities delivered in a baseline but need any deliver and rebase activities expanded.
I have tried a script to read the lines and do an "lsact -contrib" but some of the deliveries contain nested deliveries and I have become confused. It would be useful if I could also have the date of the activity as well.
I have tried experimenting with "-fmt" but with disappointing results.
The reason is that the management want to identify all activities in a baseline that contain a keyword. Currently this fails if the activity is part of a deliver oporation.
Has anyone come across a simliar requirement and if so how have they resolved it?
IBM have come up with big fat Zero, so I am looking to you gurus and wizards to give me inspiration.
No I didn't see that kind of requirement before.
Note that if an activity is part of a deliver, you will end up with a "deliver.xxx" activity in the destination Stream, with only one comment associated with that deliver (losing all the comments associated with the initial activities delivered)
So you need indeed to use lsact -contrib, following the technote "swg21136012: Activities delivered since the last baseline"
run the following command to determine what activities have been delivered since the baselines creation:
%> cleartool diffbl -activities baseline:REL1.3.117 stream:integration_stream#/vobstore/pvob deliver.development_steam.20010824.08050
>> deliver.development_steam.20010824.080503 "deliver development_steam on 08/24/01 08:05:03."
>> deliver.development_steam.20010824.080802 "deliver development_steam on 08/24/01 08:08:02."
>> ...
The above output will display the integration activities associated with the deliver operations to that stream.
If you would like to obtain a list of contributing activities for the associated integration activities, the following command can be issued for each integration activity respectively:
Example:
%> cleartool lsact -contrib activity:deliver.development_steam.20010824.080503#/vobstore/pvob
Combining that with fmt_ccase (the -fmt option you mentioned) will allow you, for each activity, to display only what is of interest (the Activity id and its comment, in order to grep for your keyword).
Related
Suppose you make a baseline in a child stream (e.g. release), name it baseline_rel_X and then at the same time you deliver the changes to the parent stream (e.g. integration) and also make a baseline there called baseline_int_Y. At that point, the baselines baseline_rel_X and baseline_int_Y are effectively the same (notwithstanding different streams, each element will be the same if compared).
Is there a way to relate (establish equality) between a baseline in the parent stream and its corresponding baseline in a child stream, in this example relate baseline_rel_X to baseline_int_Y, given that their names are different?
The reason we want to do this is to help us list all the files to be deployed to PROD, which corresponds to the parent (integration) stream above. We make many baselines in our child (release) stream, which corresponds to our TEST/UAT environment, until we collect enough changes to make one in the integration stream, which goes into PROD. You could say that there is a one-to-many relationship between baselines in PROD and TEST/UAT. So we want to take the integration baseline that is currently in PROD, relate it to its original baseline in the release stream (that unfortunately has a different name), and then do a diff between that and the most recent baseline to list all the changes we've made since we last released to PROD.
I know this sounds confusing but I am hoping it makes some sense.
Rather than trying to:
do some complex or long cleartool diffbl
rely on a naming convention you cannot change
I would record in an attribute the name of the baseline form which you did the deliver (baseline_rel_X) into the object baseline:baseline_int_Y#\pvob.
Other ways would be:
seek a baseline in rel which would be close enough of the deliver activity name (named after the stream and the deliver date): that is quite imprecise.
look for the hyperlink which should exist between the source and the destination baseline. Again, a bit complex.
Let us say I have a baseline called A1. What I then want to see if there is any way for me to be on another stream, anywhere in the same project, to see if I have A1 in my stream? I.e. do I have the code changes made in A1 in my stream?
Is there any fast way to do this? Thank you in advance.
ClearCase works based on activities, and you should determine is an activity has been delivered by using cleartool lsact -contrib:
See "Activities delivered since the last baseline", and a more complete example at "Describe baseline and expand deliver and rebase activities".
You can list all activities of a baseline with cleartool descr -l baseline:A1#\pvob.
Another case is simply when A1 is a foundation baseline in your other stream.
you can describe your other stream, using fmt_ccase format, to list only the foundation baselines and check if A1 is part of those.
See "Display Current Baseline with Cleartool".
Then you need to check if you have LATEST versions which have no 'A1' label on them.
See for instance "How to make cleartool tell if source is modified since last baseline".
As you know, sometimes a UCM activity depends on another activity, and sometimes other activities are depended on that activity. I'm wondering how can I get this information easily?
Assuming my input is an activity ID - how do I get these two outputs easily?
Thank you
The activity dependency is determined in the context of a deliver or rebase.
See "About activity dependencies in the deliver operation
So maybe the easiest way to see what activities are involved is to do a deliver -preview.
But beside that, there is no easy way to list those dependencies because they involve:
version dependency (the same file has versions in both activities, making one depending on the other)
timelines (see for instance "ClearCase : Making new baseline with old baseline activities"): a baseline made by a deliver/rebase and which will link (that is the second form of dependencies) all the activities in a given stream together. Even if they don't have any file in common.
REM output is space delimited list
view-context> cleartool lsact -fmt "%[contrib_acts]p" activityID#\pvob
act1 act2
If you make (mkbl) and compare (diffbl -act) baselines, you can obtain the same information as well as recursive delivery information.
From ClearCase GUIs (Project Explorer and ClearCase Explorer -> My Activities, you can also right click on an activity and select "Show Contributing Activities".
This answer only addresses one direction for activities. Using baselines with other %[xxx]p format specifiers for baselines should allow forward and reverse resolution.
We use clearcase UCM with 15 vobs.
We use cleartool lshistory -all -since "time" -nco vob1/ vob2/src/ vob3/tests/ ...many more... to detect changes since last time. This gives correct result, but takes too long on streams with lot of history.
Is there a way to return early if there is 'any change' on a stream, but not detailing that change? One options is to limit the lshistory to individual vobs, but that does not look elegant. I guess there is a better way to do this?
Multisite is off course not an option, due to huge license costs.
You cannot make one vob multisite without having to make its adminvob/pvob also multisite, which in turn means other vobs associated to said adminvob, while not always multisited themselves, need to pay multisite license as well!.
Depending on the level of information you are after, a simple and regular update on a snapshot view is enough to detect/update any changes, with results in the update.20xx-yy-zzT123456-0x.updt file.
You can setup a cron job in charge of:
updating the snapshot UCM views (set on the streams you want to monitor, instead of a lshistory after any modification on any stream)
concatenating the result of the various updt files.
Whenever you need to check for changes, read/parse the concatenated result made by your job (and have it reset/create new concatenated ones).
This is a bit of scripting work, but for large histories, this will be much more efficient than the slow 'lshistory -all'.
The following suggestion should be super fast compared to lshistory but it does not support any generic "time" reference, only from earlier manually saved entries. It also depends on multisite.
If you only want to check if there is any (local) change made to each of the individual vobs, you could perhaps use the multitool lsepoch command to compare the epoch number with the previous.
Edit: Since I have no experience with UCM I did not notice at first, but as noted, this answer will only consider changes from the whole vob, not individual streams as the question asks for.
I have a project where I need to perform a number of operations on a dynamic view. If any of those operations fails, or some error comes up in the program, I need to be able to back out the commits.
The straightfoward way seems to be to simply put the commands into a queue and then, when my program finishes processing, execute the queue. However, I am concerned about some exceptional event interrupting the commits and causing an inconsistent dataset on the server.
Or, in other words, I'm looking for a way to create a svn-style 'changeset' in Clearcase dynamic views. The script language I'm using is Perl, if that matters.
Ideas?
The atomicity of operation in ClearCase being at the file-level, there is no strict equivalent of a svn changeset (i.e. a "revision").
The closest thing of a changeset in ClearCase is the notion of activity (in UCM), or a label set on a collection of files (a UCM Baseline is actually closer, since it represents labels you cannot move, on a pre-defined set of files -- UCM component --)
Now, UCM or not, I would recommend:
locking the branch on which you will make checkins
(that way, the vob is still accessible, and nobody is trying to add other versions on that particular branch during your "atomic" operation)
do your checkins
unlock the branch
In case of trouble, while the branch is still lock, you can 'ct rmver' the versions added. (Note: to use with care: a rmver can not be undone)
Note1: if you are not working in UCM, you will have to record all checked-in versions in order to be able to rmver them
Note2: when I said "lock the branch", I meant of course: "lock for everyone except you" (-nusers yourLogin). That way, only you can make checkins (that applies to all files in LATEST on the branch on which you are working (main or another).
The problem, with this approach, is what the clients (the other users with their dynamic views in LATEST on the branch) will see during your atomic transaction.
Since those are dynamic views, they will see the checked-in files while these files are checked-in, one by one. That may not be good, especially if there are 200 files and if the all process takes more than a minute.
One solution would be to have those client views set their config spec to the following:
element * .../myBranch/FREEZED_LATEST
element * .../myBranch/LATEST
If you are not doing atomic changeset commit, the label FREEZED_LATEST does not exist, and all the client views are displaying LATEST, as they should. Any checkin is immediatly seen by all.
But during your atomic commit, you could:
first set a label FREEZED_LATEST on all the current files (currently in LATEST, that is)
That means, all the clients will only see those specific versions during the atomic commit
do your process (all the way, or roll back: either way, the branch is locked, and the config spec of the clients still shows the same "freezed" content)
delete the label FREEZED_LATEST (all the clients go on seeing the new LATEST resulting from your atomic operation, and can make new versions with some checkouts of their own)
With v7.1.1 ClearCase supports atomic commits.You will be able to treat a set of files as one unit and check them in or rollback based on a given criteria.For more info , for more info see
https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.relnotes.doc/topics/c_cc_relnotes_features.htm
Lock out all other users.
Do a backup of your server.
Do your commits.
If something goes horribly wrong, restore clearcase from backup.
I haven't used clearcase in years, so here are a few stray and naive thoughts.
Look ahead and determine if files are out of sync.
I would lock all the files you're about to check in before checking them in, and if you fail to lock one, abort the whole mess, with a useful message.
Can you "delete" a check in? Or revert, so HEAD looks at a previous version? Define your undo of a check in.
Can you make a temporary branch, check-in, then merge/rebase (my terminology is lose here).
That way your rollback is to kill the branch. Though I remember coworkers cursing clearcase because of it's branching.
In general, queuing actions is great, but use the queue to identify potential problems before they occur. In addition, define your actions and their UNDO criteria, so if they want to do something that isn't pseudo-atomic, you can warn them, "This might get messy".