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.
Related
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.
I have applied full baseline for my release. for ex. Baseline "MYProj_2.0.0.20".
Then testing team found some major issue. To fix that development team has delivered few changes.
After completing the build , I have applied the same baseline again "MYProj_2.0.0.20. But this time i have applied Incremental baseline. As per UCM, the baseline MYProj_2.0.0.20 was turned as MYProj_2.0.0.20.3452 (some random number at end to made it unique).
Now If i consider MYProj_2.0.0.20.3452 as release baseline, Will it contain all the changes or only the changes (delta change between "MYProj_2.0.0.20" and "MYProj_2.0.0.20.3452").
Please clarify me.
It will contain all changes.
Except an incremental baselines will compute those changes by adding:
unique modifications introduced by the few changes (that is what an "incremental baseline" is: a label set only on the new versions since the previous baseline)
all the other changes already references by the previous baselines up to a full baseline
See "Types of baselines":
A full baseline is a baseline that you create by recording all versions of all elements below the component's root directory.
An incremental baseline is a baseline that you create by recording the last full baseline and those versions of elements that have changed since the last full baseline was created.
(there are also "checkpoint baselines", as detailed in "about ClearCase baselines", created automatically by deliver and rebase operations, but you don't need to be concerned with those right now)
That is why I always prefer a full baseline: all delta operation (like a "compare with another baseline") are quicker if your last baseline is a full one.
The argument in favor of incremental baselines is that they are faster to create (because of the lesser number of version to put baseline on).
But if your UCM component is so large that putting a label on all its versions is too long, maybe your component is too big in the first place.
Note that you always can upgrade an incremental baseline to a full baseline.
Note also that you have a difference between:
the title of a baseline (here "MYProj_2.0.0.20": you can put as many "MYProj_2.0.0.20" baselines as you want)
the id of a baseline (always unique: if "MYProj_2.0.0.20" is already taken, then ClearCase generate some numbers at the end: "MYProj_2.0.0.20.3452")
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.
What is difference between branches and streams in ClearCase?
A branch is a classic versioning way to parallelize the history of versions for a given file: See "When should you branch"
A Stream is not a branch: it is just a metadata able to memorize what baseline any view referencing that Stream will see.
When you create a Stream, nothing happen (no branch is created).
But a Stream name will be used when a file is checked out: any view will set its config spec in order to create a branch named after the Stream in order to isolate the development effort in said branch.
(See "How do I create a snapshot view of some project or stream in ClearCase?")
This is why it is important to adequately name a Stream: If I create a Stream named "VonC", you will eventually see (in the version tree for any modified file) a branch named "VonC": what is the purpose of a branch "VonC"?
If I create a Stream named "REL2.2_FIX", you will see branches named "REL2.2_FIX" and will infer that any view referencing that Stream is there to produce fixes on the release 2.2: a much more useful name. (This is why I don't like the "one stream per developer model")
So if you have any writable component, a Stream could be considered as a template for branches:
You declare what you need in a stream (what baseline you want to see)
You create a view on that stream
Any checkout will create a branch named after the Stream.
(And that is why so many UCM users mix or equate "Stream" with "branch")
But if you have only non-writable components in your project, then a Stream is just the list of baselines (labels on components) that you want to see in any view you will create on said Stream.
That becomes a visualization mechanism, useful for testing environment where you only need to access precise versions of a set of components in order to test your system.
In that case, no branches will ever be created, since no checkout will ever be made on any file: the component are declared non-writable in the UCM project.
The other major difference between a Stream and a branch is the organization of Stream in a hierarchy (parent Stream / sub-Streams).
That hierarchy simply don't exist for branches: when you have 3 branches A, B, C:
you don't know where to merge from branch A once you have finish your work on it.
any merge you do has the same meaning: A->B, or C->A, or B->C, or ...
With Stream, you would have:
MyProject_Int
|
--MyProject_Dev
|
-- MyProject_Feature1
The hierarchy of Streams is there to:
introduce a possible workflow of merges (you know where you should merge from one Stream to another: namely its parent. It is not mandatory, but at least you have a visual way of knowing that:
Feature1, once fully developed, will get back (be merged to) MyProject_Dev (its parent Stream), and that:
MyProject_Dev, once a stable state is reached, can be merged into its parent Stream MyProject_Int, where integration tests can be conducted while development go on uninterrupted in MyProject_Dev.
add a meaning to those merges:
merging from a sub-stream to its parent or any other parent stream (for instance, you can merge directly from MyProject_Feature1 to MyProject_Int if you have to) is called a deliver.
merging from a parent Stream (like MyProject_Dev) to an immediate sub-Stream (like (MyProject_Feature1) is called a rebase.
Its purpose is to ensure that Feature1 is developed with the latest changes of Dev, in order to make the final deliver as painless as possible: with regular rebases, the common set of code would not have diverged too much between the two parallelized histories of those two branches derived from those two Streams.
Keep in mind that those two UCM operations deliver and rebase are, at their core, no more than simple merges between two branches A and B.
However, because of their names, you know that you don't merge just between any two branches, but between a sub-Stream and a parent Stream (deliver), or between a parent Stream and a sub-Stream (rebase).