My Requirement is regarding clearcase delivery:
I want to automate delivery(no manual intervention/no deliver failure) process:
While delivering - if there is any merge issue
1.if CC is able to merge files, its good- let it merge,
2.if CC is not able to merge - i don't want it to fail, instead lets not merge that particular file(revert merge for that file), proceed with next files.
3.List the files that are skipped, so that i can manually merge later.
i doubt we can do this in a single step, but let me know if this is possible, and process to do it.
you can click "skip all" during a merge, but you will have to resolve them in one way or another.
The easiest way is to make sure those files aren't considered for merge in the first place (see below).
But there is no native way to automate the process you describe:
While delivering, if there is any merge issue
if CC is able to merge files let it merge,
if CC is not able to merge - I don't want it to fail, instead lets not merge that particular file (revert merge for that file), proceed with next files.
List the files that are skipped, so that i can manually merge later.
You would need to write a script to manage those case, and even in this case it wouldn't work for an UCM merge (deliver/rebase), which won't complete until all files have been merged (hence my "red arrow" suggestion below)
That script would basically take the output of a cleartool findmerge -print (to get all directories/ files to merge), and then merge first the directories, and then the files one by one, applying the policies your are afer.
for making sure a certain file is always ignored
for the current merge:
You can simulate the merge by displaying the version tree and right click on the source version: "merge to" and select "do not merge, draw the merge arrow" (red arrow, which represents a merge arrow, as seen in this illustration).
The idea is to trick the current deliver into believing that this file has been merged even though you haven't do any modification during that merge (you just have drawn the red or merge arrow between the source and destination version).
for the future merges:
You can change the merge manager associated to a type of file in order to never merge it.
See "Handling Binary Files in IBM Rational ClearCase", which explains how to create a new special type manager:
You can then apply that merge manager to a specific file with cleartool chtype.
initially i tried below commands to get the list of file to merge(file names, activities are renamed to avoid confusion):
cleartool findmerge activity:a#\a_pvob activity:b#\a_pvob -fcsets -ftag Accept_deliver_stream -type d -merge -log c:\temp\am.log
cleartool findmerge activity:a#\a_pvob activity:b#\a_pvob -fcsets -ftag Accept_deliver_stream -type f -print -log c:\temp\af.log
so it returned list of commands to af.log file, when i am trying to execute those commands, it just hangs even after one hour, one command is:
cleartool findmerge M:\WM2011_DEV_INTG_WMOSBUILD_01\WM08\CPP\base\foundation\general\invupdates\InvUpdate.cpp -fver \main\Mainline_Int\WM08_Integration\WM09_Integration\WM2010_DEV_INTG\MAIN_WM_Int\WM2012_IND\9 -log NUL -merge -cqe
Related
I want to merge all files from a particular branch to main using a script or a command. Is there a way to do it without checking out each file in target or should i do each file manually.
ClearCase is file-based, not repository-based: any merge will be done file by file, and actually first folder by folder (you merge the folders first, then the files).
The easiest way to initiate a merge based on a branch is to use the cleartool findmerge, which can use a version selector, like -fve/rsion .../branch1/LATEST.
See also "To prepare to merge"
The usual approach though is to use a view or a tag to select the elements you want to merge, as I described in "How merge sub branch to main branch using clearcase command line under linux?" (using -ftag).
Note that this works also in an UCM environment, based on activities (even though the deliver and rebase commands remain the recommended merge methods).
I can compare two files in Winmerge by triggering a comparison on the command line with a command similar to:
WinMergeU C:\file1.txt C:\file2.txt
I can query a list of files with particular properties in clearcase with a clearcase query similar to:
Y:\VOB_A>cleartool find . -type l -exec "cleartool describe -fmt "%n %[slink_text]Tp\n\n\" \"%CLEARCASE_PN%\""
.\Directory\createsymlink.txt -->..\..\VOB_B\SymlinkFolder\createsymlink.txt
What I want is to generate a set of clearcase query results that can then be used as input to winmerge (ie generate a bunch of diff commands on checkins fulfilling a certain criteria like user or day).
How can I write a clearcase query to get a list of file elements (referable in clearcase ie winmerge could open the path to the version on a dynamic view), and get their corresponding previous version of the file?
The bit to format this to winmerge I imagine would look somewhat like this:
... describe -fmt "WinMergeU ...
One, you would need to generate the right full extended pathname for each file (one being the result of your query, one being the previous version of the one found by said query)
Two, you need to do so in a dynamic view (in order to access to any version though the extended path name of the file.
Once your query gives you a version, you can ask, with a cleartool descr -fmt "%PSn" (see fmt_ccase man page), for the previous version and add that to your result file.
Trying to do it all in one pass (find + predecessor version + WinMerge call) seems too complicated.
I'm testing a clearcase merge script and I'd like to be able to have another script that could produce these 2 test scenarios every time it runs:
Modify 3 files for a trivial merge (100% automatic, no diff needed)
Modify 3 files for a conflicting merge, user resolution required
What I'd like to know are the steps/clearcase commands needed to prepare these files. All must be done through command-line (using cleartool commands). I already have a dynamic view and some test files I can use. Probably I'll need to create a destination test branch too.
The merge is done using the ct findmerge command like this:
`cleartool findmerge filepath -fver version -merge -log NUL -c comment`
I need to validate the output in each of the cases, to include them in a report and also ensure that no user interaction is required.
You need:
to have two branches where you makes your parallel evolutions in your files
to use simply cleartool checkout -nc myFile ; echo new modif >> myFile ; cleartool checkin -nc myFile for adding evolution with a trivial merge in one branch (leave the same file untouched in the other branch)
to use the same process in both branches with a different echo each time in order to add a new line different in both version of myFile: that will result in non-trivial merge.
Don't forget that you can also have trivial/non-trivial merges on the directory level (when files are added/removed): a non-trivial one would be in case of an evil-twin.
We use UCM for development. We create streams under streams, like this
Question is how to find new files in a given stream.
In the example "feat1" would have new files relative to its parent lis1 (lis=local integration stream). The new files could be from "feat1" or its child streams like "developer1". How could I identify new files in lis1?
One option is to create dynamic views on a stream (say feat1) and its parent stream(lis1) and take diff and figure out files new in the child stream.
Another option is to use cleartool deliver -preview and get list of versions and then somehow (I do not know it yet) figure out the list of files.
The problem is the child stream is not necessarily rebased to its parent, and we enforce a "rebase to latest baseline before delivery" rule.
I hope there is a better and correct way :)
I don't think a cleartool deliver -preview (like its non-UCM equivalent cleartool findmerge -preview) would display the full list of modified/new files.
For new files, it would only display the directories that need merges (in order to reference or un-reference the files added/removed during that merge).
One way (without using an external diff tool) would be a cleartool find request in order to find any file:
with versions in a 'developer1' branch
without any versions in a 'lis' branch
Something like (not tested):
cleartool find . -type f -version "brtype(developper1) && !brtype(lis)" -print
In the OP Jayan's case:
cleartool find . -type f -element "brtype(developper1) && !brtype(lis)" -print
Will list only the needed elements (ie files, and not all the versions of those files)
Could anyone explain what is a Evil Twin and Subtractive merge in Clearcase?
Evil Twin
An Evil Twin is an element that you have removed (using rmname) and want to re-add, but it's 'evil twin' exists in previous versions of the directory.
You have to remember that each element had a unique ID, so you are attempting to add an element with the same name - but with a different UID. This is not allowed.
The best way to deal with an Evil Twin is to relink the newest version you can find of the existing element to the new version of the directory. You can then make a new version of the element and replace the data within it.
Subtractive Merge
A subtractive merge is the opposite of a selective merge.
A selective merge (the default, bog standard merge) adds the changes from another element version into your checked-out version.
A subtractive merge attempts to remove the changes made in a different version from the version you have checked out - because it's a bad version, you've made mistakes in it etc.
IBM has a nice article on substractive merge.
A subtractive merge can be performed to exclude or bypass bad versions on a branch without actually removing the bad versions.
Cleartool merge using the -delete option will allow a user to merge from the last known good version to a new version on the same branch which excludes the work done in the versions identified as bad versions.
This merge must be performed from the command line, it does not create a merge arrow, the arrow can be created manually.
This will work for file as well as directory
But you need to realize that merge is about a file or a directory, not about a directory "and everything in it".
To merge recursively, take a look at findmerge.
You can want to merge only directories (since they are always merged first, to determine the actual list of files to merge!), as in this IBM article
% cleartool setview major_vu% cleartool findmerge /vobs/vob1 /vobs/libvob2 –type d \
–fversion /main/LATEST –merge
you may also do the merge from the LATEST version of a branch or from a tag:
findmerge . –fversion /main/rel2_bugfix/LATEST –print
findmerge . –ftag rel2_bugfix_view –whynot –print
Note: the -print is always a good idea before replacing it by '-merge -gmerge', in order to get a preview of what will be merged. But if directories are involved, it will only print that 'directory X' needs to be merged, not the exact list of files.
For evil twins, check out the IBM article. Case sensitive issues can be a real pain to deal with and create some evil twins without you realizing it...