I have to merge all objects from a sub branch to main branch recursively. I would like to merge manually by check in the code from sub branch to main branch instead of using merge command in clear case.
So after the check in into the main branch I would like to draw arrow
recursively to all my objects.
ic from sub branch to main branch
I have used this command
cleartool mkhlink -unidir Merge <sub branch path>>##/main/<<sub branch>> <<main brach path>>##/main/LATEST
But when I dit it, it is drawing the arrow for the directory only not for all contains of the directory.
Please suggest how to draw the arrow recursively from sub branch to main branch objects.
Thanks in advance
According to the merge man page,
cleartool merge -ndata -to aFile -version /main/a/SourceVersion /main/a/DestVersion
will draw a red arrow without performing any actual merges.
Since you have made your checkout/checkings in a branch or a UCM activity, what you need to do is:
be in your destination view (the one where the merge occurred)
query all the versions you made for that merge
extract the file for each version
extract the destination version
compute the source version (for instance /main/aBranch/LATEST)
do a "merge -ndata"
So, it is not so much a "recursive" algorithm, but rather an enumeration of all versions involved in this merge in order to draw the appropriate red arrows.
Just use the ClearCase Merge Manager - it should take all the pain out of doing a task like this.
I know this is 8 months later but have you tried this?
cleartool find . -type f -nxname -exec 'cleartool merge -to $CLEARCASE_PN -ndata -version /main/aBranch/LATEST '
Probably do not need the -nxname in the first part. I changed to the directory that I wanted to create only merge arrows to and did a FIND for everything in the directory.
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).
I'm writing a MEL script that will rename all of the joints in a joint hierarchy to a known format. The idea is that you would select the Hip joint and the script would rename the Hips, and go through every other joint and rename it based on its position in the hierarchy.
How can you traverse through a joint hierarchy in MEL?
If you assign to $stat_element the name of your top joint in the hierarchy and run the following code, it will add a prefix "myPrefix_" to all children elements of that joint.
string $stat_element = "joint1";
select -r $stat_element;
string $nodes[] = `ls -sl -dag`;
for($node in $nodes){
rename -ignoreShape $node ("myPrefix_" + $node);
}
Hope this helps
If you need to make detailed decisions as you go along, instead of bulk-renaming, traversing the hierarchy is pretty simple. The command is 'listRelatives'; With the 'c' flag it returns children of a node and with the 'p' flag it returns the parent. (Note that -p returns a single objects, -c returns an array)
Joint1
Joint2
Joint3
Joint4
listRelatives -p Joint2
// Result: Joint1 //
listRelatives -c Joint2
// Result: Joint3, Joint4
The tricky bit is the renaming, since maya will not always give you the name you expect (it won't allow duplicate names at the same level of the hierarchy). You'll need to keep track of the renamed objects or you won't be able to find them after they are renamed in case the new names don't match your expectations.
If you need to keep track of them, you can create a set with the set command before renaming; no matter what becomes of the names, all of the objects will still be in the set. Alternatively, you can traverse the hierarchy by selecting objects and renaming the current selection -- this won't record the changes but you won't have problems with objects changing names in the middle of your operation and messing up your commands.
It can be messy to do this in MEL if you have non-unique names because the handle you have for the object is the name itself. Once you rename a parent of a node with a non-unique name, the child's name is different. If you stored the list of all names before starting to rename, you will get errors as the rename command will attempt to rename nodes that don't exist. There are 2 solutions I know of using MEL. But first, here's the pyMel solution which is much easier and I recommend you use it.
PyMel Solution:
import pymel.core as pm
objects = pm.ls(selection=True, dag=True, type="joint")
pfx = 'my_prefix_'
for o in objects:
o.rename(pfx + o.name().split('|')[-1])
As pm.ls returns a list of real objects, and not just the names, you can safely rename a parent node and still have a valid handle to its children.
If you really want to do it in MEL, you need to either rename from the bottom up, or recurse so that you don't ask for the names of children before dealing with the parent.
The first MEL solution is to get a list of long object names and sort them based on their depth, deepest first. In this way you are guaranteed to never rename a parent before its children. The sorting bit is too convoluted to be bothered with here, and the recursive solution is better anyway.
Recursive MEL solution:
global proc renameHi(string $o, string $prefix) {
string $children[] = `listRelatives -f -c -type "joint $o`;
for ($c in $children) {
renameHi( $c ,$prefix ) ;
}
string $buff[];
int $numToks = tokenize($o, "|", $buff);
string $newName = $buff[( $numToks - 1)];
$newName = ($prefix + $newName);
rename($o,$newName);
}
string $prefix = "my_prefix_";
string $sel[] = `ls -sl -type "joint"`;
for ($o in $sel) {
renameHi($o, $prefix);
}
This recursive solution drills down to the leaf nodes and renames them before renaming their parents.