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.
Related
Background
In Clearcase, you can get the graphical version tree of a file by entering the following command in a linux terminal.
ct lsvtree -gra <filename>
This brings up an interface with numerous options to look at the diffs between two versions of a file.
Problem
From the graphical tree interface, I am trying to find if a string exists across any version of the file. This string was lost at some point, and I want to figure where that "somepoint" is.
Question
How can I run a text search across all versions of a file in clearcase?
As I mentioned before (2015), there is no equivalent to a git log -S or -G (pickaxe search) in ClearCase.
That pickaxe search is done (in Git) to point out past revision where a string has been added or removed.
But: you would need to script the equivalent feature for ClearCase.
Since cleartool lsvtree shows you all the version of a given file, you can, starting with the most recent version do a cleartool annotate to see when, and in which version, the line was added.
If that line include your string, then this version would be relevant.
If the most recent version does not include your string, then repeat the process with the previous version (do a cleartool annotate on that previous version, if it includes your string).
If you use dynamic views, you could take advantage of how it accesses element versions via version-extended naming. using "foo.c##/main/branch/1" as an example, you have "foo.c##" as the root of a directory structure, with "main" and "branch" being subdirectories, and "1" being a "file"
You can use this by doing the following:
cd to "foo.c##"
Perform your search.
For example:
cd foo.c##
grep -rl "target-string" *
to get the files without the string:
cd foo.c##
grep -rlv "target-string" *
You could also use lsvtree output to power a search in a script, but the above is is the simplest trick to do this. This works on Unix and Windows, but you may want to use something other than the standard Windows "findstr" if your target string contains multiple words, as findstr handles them strangely: findstr "foo bar oof" will print lines that contain "foo", "bar", or "oof", occasionally even when /L for "literal" is used.
If you're using snapshot or web views, this is a lot trickier and will need a script to iterate on the output of lsvtree.
I am running a job on Jenkins which is used to create a view on ClearCase and the ClearCase view creates the default config spec.
I want to edit the config spec by adding some more lines to it but I don't want to edit it manually every time. So I am looking to add some script to Jenkins so that it can edit the configspec every time when it runs the job.
Is there anyone how is clear case expert who can task it out.
Once your ClearCase view is created you need to get its config spec as a file with cleartool edcs
cd /path/to/view
cleartool catcs > cs
You need to adds your selection rules before the default one: as mentioned in config spec
Because the rules in a config spec are processed in order, varying the order may affect version selection. For example, suppose this rule appears near the beginning of a config spec:
element * /main/LATEST
Any subsequent rules in the config spec will never be used, because the rule always provides a match; every element has a most recent version on its main branch.
Note:
The order in which the load rules for a snapshot view are specified is not important.
To script that, please see "Using sed, Insert a line below (or above) the pattern?".
Another option: see "How to insert the content of a file into another file before a pattern (marker)?".
Put your additional lines into a file named othercs.
#!/bin/bash
while IFS= read -r line
do
if [[ "$line" =~ .*CHECKEDOUT.*$ ]]
then
cat othercs
fi
echo "$line"
done < cs
Once that is done, you can append any additional load rules you want (if you are using a snapshot view, since a dynamic view has no load rules)
Finally, once the cs file has the right selection/load rules, you set it back to the current view with cleartool setcs.
cleartool setcs -tag view-tag cs
^
|
name of the file you have modified
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).
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
Given a build process like this:
Run a VerySlowProcess that produces one output file for each given input file.
Run a SecondProcess on each output file from VerySlowProcess
VerySlowProcess is slow to start, but can handle additional input files without much extra delay, therefore it is invoked with several input files. VerySlowProcess may access additional files referenced from the input files, but we can not match the file accesses to specific input files, and therefore all derived output files from VerySlowProcess will get the same Configuration Record by clearmake.
Since VerySlowProcess is invoked with several input files (inlcuding input files that has not changed) many of the output files are overwritten again with identical content. In those cases it would be uneccesery to execute SecondProcess on them and therefore output is written to a temporary file, that is only copied to the real file if the content has actually changed.
Example Makefile:
all: a.3 b.3
2.stamp:
#(echo VerySlowProcess simulated by two cp commands)
#(cp a.1 a.2_tmp)
#(cp b.1 b.2_tmp)
#(diff -q a.2_tmp a.2 || (echo created new a.2; cp a.2_tmp a.2))
#(diff -q b.2_tmp b.2 || (echo created new b.2; cp b.2_tmp b.2))
#(touch $#)
%.3: %.2 2.stamp
#(echo Simulating SecondProcess creating $#)
#(cp $< $#)
If only a.1 is changed only a.2 is written, but SecondProcess is still executed also for b:
> clearmake all
VerySlowProcess simulated by two cp commands
Files a.2_tmp and a.2 differ
created new a.2
Simulating SecondProcess creating a.3
Simulating SecondProcess creating b.3
As a workaround we can remove the '2.stamp' from the '%.3' dependencies, then it work to execute like this:
> clearmake 2.stamp && clearmake all
VerySlowProcess simulated by two cp commands
Files a.2_tmp and a.2 differ
created new a.2
Simulating SecondProcess creating a.3
Is there a better way to handle our problem with VerySlowProcess?
Your workaround seems valid.
The only other use of clearmake for supporting "incremental update" is presented here, but I am not sure if it applies in your case.
Incremental updating means that a compound object, such as a library is partially updated by the rebuild of one or more of its components, as opposed to being generated by the build of just one target.
The use of the .INCREMENTAL_TARGET is of importance here.
This special target tells clearmake to merge the entries of the target's previous configuration record with those of the latest build.
This way the build history of the object is not lost, because the object's configuration record is not completely overwritten every time the object gets modified.
Here's an alterative scenario though similar problem...perhaps...though your description does not quite match my scenario.
I have a very slow process that may change certain files but will regenerate all the files.
I want to avoid the slow process and also want to avoid updating the files that do not change.
Checked if regeneration (slow process) is necessary - this logic needed to be separated out from the makefile into a shell script since there are issues with clearmake with targets being updated and .INCREMENTAL could not help resolve.
Logic Overview:
If the md5sums.txt file is empty or the md5sums do not match
then long process if invoked.
To check md5sums:
md5sum -c md5sums.txt
To build slow target:
clearmake {slowTarget}
this will generate to a temp dir and afterwards update the changed elements
To regenerate md5sums:
checkout md5sums.txt
cleartool catcr -ele -s {slowTarget} | sed '1,3d;s/\\/\//g;s/##.*//;s/^.//;' | xargs -i md5sum {} > md5sums.txt
checkin md5sums.txt