When delivering stream A to stream B, is it possible only to deliver selected elements (directories to be precise) from A to B?
When rebasing a stream A from a baseline B, is it possible only to rebase selected elements (directories to be precise) from B to A?
With ClearCase UCM:
what you are delivering are baselines or activities
what you are rebasing are baselines only.
(and only baselines coming from the direct parent Stream, at that).
So if you directories or elements are the only items of an activity, and that activity doesn't depend on other activities (which can happen when a deliver to another Stream has already been done: all present activities are "linked together" by a technical baseline), then you can deliver just those items (by delivering only that activity).
If your directories and files are then only difference between the source baseline and the foundation baseline you are about to change on the Stream you are rebasing, you can rebase just those items.
But the fact is: it is difficult to make partial deliveries or rebases with ClearCase.
cleartool findmerge does exactly what you are looking for. You'd need to build a wrapper (ANT/Perl) around it if your list is long.
so go to the target stream/view context and run findmerge srcdir –type d –merge -print to test and replace -print with -exec,-gmerge,-abort etc. as you need. Just replace srcdir with your directory or an iterative list/variable/array in your script.
Find complete details look at http://www.ipnom.com/ClearCase-Commands/findmerge.html
Related
Can some one please help me with ClearCase command to deliver baselines from one stream to another stream.
I have a project stream xyz_1.1.0: we have created a new stream by using release id 1.1.0 to provide a fix. The new stream can 1.1.0.17001.
Now when the stream is generated, it contains the foundation baseline from 1.1.0 but I want baselines the latest fix which is went over 1.1.0 for example it can be 1.1.0.17000... in which case I want to apply baselines of 1.1.0.17000.
We use common stream to do our checkins, hence I can get the latest baselines from common stream which can be found under recommended baselines.
A deliver (intra or inter-project, which might need the right policy to be enabled first) needs to use the cleartool deliver command.
You need an UCM view on the destination stream (the stream to which you are delivering)
And you need the latest foundation baseline produced on the source stream (otherwise, it would deliver by default all activities in the stream that have changed since the last deliver operation from the stream).
That also means you know which UCM component you want to deliver.
See "List the latest baseline of a component in a UCM stream one by one".
For a given component:
bl=cleartool lsbl -comp C -stream stream:aSourceStream#/aPVob|tail -1
cleartool deliver -baseline ${bl}#/apvob -to aViewOnDestinationStream#/apvob
Or, as commented by the OP A.Learn, you can use for delivery the recommended baseline of the source stream:
$baselines = "cleartool desc -fmt \"%[rec_bls]CXp\" stream:".$productStream."\#\\".$pvob
//Below command applies the baseline
cleartool rebase -f -baseline ".$baselines." -complete
//Finally recommend the new baselines
cleartool chstream -recommended -default stream:".$StreamName."\#\\".$pvob
This is using the fmt_ccase format applied to cleartool describe.
I have a view in which I have checked-out 9 files , another team member wants to merge my changes in his activity but I do not wish to check in the files.
Is there a way to merge files without check in or some other alternative.
One way would be to use cleartool diff, in order to generate patches, that you can then compressed and mail in an archive (.zip), for the other developer to apply.
See cleartool diff.
That would be something like:
cleartool lsco -all -s -cview | xargs cleartool diff -diff_format -pred
The -diff_format option causes both the headers and differences to be reported in the style of the UNIX and Linux diff utility, writing a list of the changes necessary to convert the first file being compared into the second file, as follows:
The first number (or range of numbers in the form n,n) indicates line numbers in the first file being compared.
The second value is one of the following: a d c. These indicate whether lines are to be added, deleted, or changed.
The second number (or range of numbers) indicates line numbers in the second file being compared.
I created one stream and now I would like to know the procedure to transfer the mastership of the stream in a different location? what are the steps should I follow?
Any help will be appreciated.
Thanks !!
You can start by following "Transferring mastership of a stream"
In some cases, you must manually change mastership of branch types or activities associated with a stream.
The output of the chmaster command includes a list of these objects.
The output may also include an instruction to run the chmaster –stream command with the -override option. This option transfers mastership of objects whose mastership was not transferred during the original invocation of the command.
For example, to transfer mastership of the stream v2.1.bl5 and its associated objects to the boston_hub replica:
multitool chmaster -stream boston_hub#/vobs/dev stream:v2.1.bl5#/vobs/dev
Attention: Do not use -override unless the output of chmaster –stream indicates that you should do so.
This is part of the more general section "Changing mastership of VOB objects", and based on the multitool chmaster command.
This is also part of procedures like "To deliver to a nonmastered target stream (MultiSite)".
How can I check if the code in a stream A has been delivered to stream B using the command line. Internally we are using Clearcase UCM.
Thanks
You need to check the difference between stream A and stream B, using cleartool diffbl:
cleartool diffbl -act stream:Stream1#\aPVob stream:StreamB#\aPVob
What you are looking for are unlabelled baselined (technical baselines set by ClearCase), created from activities (hence the -act) named deliver.xxx:
Differences:
<< deliver.java_dev.19990917.140443 "deliver java_dev on 09/17/99 14:04:43."
<< deliver.java_dev.19990917.141046 "deliver java_dev on 09/17/99 14:10:46."
If you describes those activities, you will know what versions have been delivered.
cleartool descr activity:deliver.java_dev.19990917.140443#\aPVob
The issue is: once delivered, what you get in streamB is one giant activity (the "deliver.xxx" one) with all the delivered versions in it.
You don't have directly the list of contributing activities which were on StreamA, and were part of the deliver.
To see those contributing activities, you can look at the technote "Activities delivered since the last baseline":
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
ACT0000435
I have a given file on a given child stream. I want to compare the version on the stream to the same element on another stream. To do this, I need to figure out if the file has been moved on the child stream so I know what name to look for on the parent stream. However, there doesn't seem to be an easy way to find rename events using the command line tools.
The only way I could find was to use cleartool diff on each version of the parent directory to look for the diff containing the rename, but it seems like there should be an easier way.
The main options are summarized by this thread and mention a search based on the OID o the file.
But I would first try a cleartool lsvtree:
cleartool lsvtree -obs -branch theOtherBranch myFile
Try that from the "source" view (that is the one selecting the file with its current name in the current branch), and see if the lsvtree is able to display the version of that same file on the other branch.
The OP bradtgmurray reports:
lsvtree lists element history with the current name for whatever stream, which isn't what is needed for detecting renamed file.
the thread help suggesting the use of:
cleartool desc -fmt '%On' <filename>## in the child and
cleartool desc -fmt '%n' oid:<oid> in the parent.