I have a ClearCase main branch, and have a subbranch A created out of main branch.
Once again I have subbranch B created out of Subbranch A by editing the config spec.
Now I need to merge the files present in both the branches using findmerge command.
There are some files in sub branch A, which are not checked-out in subbranch B. So, what is the way I can have the latest files from both the nested branches to be merged to main branch using findmerge command.
findmerge . -fversion /main/brancha/branchb/latest -print
That gives only files changed under branch B and not on branch A.
There are some files for which branchB was not necessary and files are not created under Branch B.
You need to merge:
first branchA: findmerge . -fversion /main/brancha/latest -print
then branchB: findmerge . -fversion /main/brancha/branchb/latest -print
That way, you will find files from branchA, and then files from branchB.
Another option is to have a view (I'm giving it a view tag, 'other_view' in this example) whose config spec that selects branch B first and then branch A, for example:
element * .../branchB/LATEST
element * .../branchA/LATEST
element * /main/LATEST
From a view selecting /main/LATEST, you can then use the '-ftag' option to 'findmerge' to merge from the versions selected by that "other_view". The following command will preview what will be merged:
cleartool findmerge . -ftag other_view -print
Although the answers from #VonC and #hack will both work and are fine for just identifying what content will need a merge, in many cases the best approach to actually perform the merge is to merge from branch B to branch A (resolving any conflicts along the way) and then merge from branch A to main.
from a view with branch A active in the config spec: findmerge . -fversion /main/brancha/branchb/latest -merge
from a view with only main active in the config spec: findmerge . -fversion /main/brancha/latest -merge
This allows you to resolve any merge conflicts in branch A rather than in main, reducing the risk of breaking the build for the rest of the team. In some cases it won't make sense (if branch A is explicitly not supposed to contain the content from branch B), but when it does, I find it to be the better option for no extra work.
Related
I am trying to merge my development branch with the parent branch to the one I am working in. I do not have graphical ClearCase, I only have the command line. I am using Solaris-10.
When I do lsvtree on the file, the last 3 results I see are:
filename##/main/release2/10 (PROD_REL2.0, PROD_REL2.1, PROD_REL2.2, ...)
filename##/main/release2/myprivateview
filename##/main/release3/myprivateview/1
When I do a describe on the file, I get:
version "filename/##/main/release3/myprivateview/1"
...
predecessor version: /main/release3/myprivateview/0
I want to merge my changes into the main branch so that other users can see my changes.
I have tried :
cleartool findmerge -all -fver /main/release2/LATEST -print
cleartool findmerge -all -fver /main/release2/10 -print
cleartool findmerge filename -fver /main/release2/LATEST -print
cleartool findmerge filename -fver /main/release2/myprivateview/0 -print
and various other combinations.
What happens is it thinks for awhile and then prints...nothing. No error messages, nor listing of merges, nor conflicts, nothing at all gets printed.
I have checked that my view is dynamic. What am I doing wrong?
Whenever you do a merge or findmerge, you need to do so in a view set to reflect the destination branch (here the main branch, which seems to be for you release3)
So setup another dynamic view, used for the merge, with:
element * CHECKEDOUT
element * .../release3/LATEST
element * /main/0 -mkbranch release3
element * /main/LATEST -mkbranch release3
Here, release3 would be the destination branch, that is the branch you are merging to.
In that view, try your findmerge command again.
Note that, as I explained here, you would need to findmerge (and merge) your folders first, then your files.
Thank you #VonC for your advice.
I could not figure out how to create a new view with the config specs you mentioned above.
However I discovered that there is no need to create any new views at all: All I had to do was change my own view to point to the branch level that I wanted to change.
What I did is:
1) $ cleartool edcs
2) save the config specs that were displayed somewhere else
3) edit the file to look like this:
element * CHECKEDOUT
element * .../release3/LATEST
element * /main/LATEST -mkbranch release3
4) $ exit (to reload the view with the new config specs, not sure if this was necessary)
5) $ cleartool setview myprivateview
6) $ cleartool findmerge filename -fver /main/release3/myprivateview/1 -print
7) $ cleartool findmerge filename -fver /main/release3/myprivateview/1 -merge
8) cleartool ci filename
9) cleartool edcs
10) replace config specs as they were before`
This performed the merge exactly how I wanted and these steps will work to merge into any level, without having to create any views.
How Can I check if a label has been applied on main branch or the project branch?
I have a label which we apply on all the elements in a VOB in main branch, but I just found out that the label is applied on certain elements in a project branch.
Therefore I now need to make checks to find if any other elements on the sub branch have this particular label.
I now need to make checks to find if any other elements on the sub branch have this particular label
A cleartool find query shoould be enough:
cleartool find -all -version "lbtype(mylabel) && brtype(mybranch)" -print
Well, I'd make a slight change in case there were multiple project or developer branches:
cleartool find -all -version "lbtype(mylabel) && !brtype(main)" -print
This would print only the versions that have the label that AREN'T on /main.
Yes, I know it's a quibble...
I had the same question as posted here:
Cleartool findmerge select changes from file 2 by default in all cases?
I tried the recommended fix (performing a clearfsimport from the source view to the destination view). I did this by (on Linux) setting a dynamic view for the destination, cd-ing into the VOB tag, then using /view/[source_viewname]/[vobname]/* as the source for the clearfsimport. The problem with this is that it attempts to create evil twins, which doesn't help the situation.
Are there any other ways of doing what's being asked in the original question posted above?
You could try a mixed approach:
use findmerge -ftag -merge -abort, as suggested: that should at least merge the folders.
for each folder where there is a conflict, use clearfsimport.
The key, to avoid any evil twin, is to make sure the folder is merged first (that will create entries for the files of that folder).
Then the clearfsimport won't try to create new files, but will update those entries, avoiding the evil twins.
The OP karl_ proposes in the comments:
I think I'll do the following:
findmerge -type d -abort on the first pass, let manual merges fail
findmerge -type d -exec "ct merge (manually merge the element from source)"
findmerge -type f -abort on this pass, let manual merges fail
findmegre -type f -exec "ct merge (manually merge the element from source)"
That is the right plan: first merge folders, then files. That way, no evil twins.
I have somehow created a branch of a file in clearcase UCM that is not part of an activity. I have no idea how to reproduce this, but my stream is showing many files with this symptom. How can I find these files, remove them, and prevent it from happening again in the future?
Here is an example of one such file, names redacted to protect the innocent:
xxxxxxxxxxx.cpp##/main/xxx-integration/xxxxxx-xxxxxxxx/0 Rule: .../xxx-xxxxxxx/LATEST
A ct lsact -long | grep <filename> returns no results.
Update:
I used a find command to track down all the files that are on the branch given (and redacted) above, though I still do not understand the issue.
Per VonC's answer, where is what I ended up doing:
cleartool find . -type f -version "version(.../xxx/LATEST)&&version(.../xxx/0)" -print | tee ~/tmp/files2
I then read through the list of files generated to make sure they made sense, then I verified they were not attached to an activity and removed the versions:
cat ~/tmp/files2 | while read
do
if [ -z "$(ct describe -fmt "%[activity]p" $REPLY)" ]
then
ct rmbranch -f ${REPLY%/0}
fi
done
That can happen ig those file were checkout in a base ClearCase view, ie a non-UCM view, withg a simple config spec:
element * .../xxx-integration/LATEST -mkbranch xxxxxx-xxxxxxxx
You can use a find command similar to "How can I find all elements on a branch with version LATEST that has no label applied?".
The difference is: for each version found, you need to describe it in order to check if there is an activity attached to it or not (with a fmt_ccase):
cleartool describe -fmt "%[activity]p" "$CLEARCASE_XPN"
I'm trying to reduce access times to ClearCase a bit, and am thinking about removing all the unused branch types (i.e. ones where no element has a branch of that type in the VOB). Is there a simple query that can return unused types, or do I have to scan for instances for each of the existing types?
I prefer something Cleartool or CAL based, as I want to build a tool that can be used by others.
I didn't see any "simple query", so it is best to check for each brtype instance in each vob.
First get the list of brtype for a given vob:
cleartool lstype -s -kind brtype -inVOB
(a bit like in the "Send to mkbranch script")
Then make a cleartool find to check if any version of a given element exists for one specific brtype.
cleartool find /aVobTag -element "brtype(aBrTypeName)"
Note: looking for elements is faster than looking for version here.
If you have the same name of brtype used in multiple branches, the "Additional examples of the cleartool find command" page illustrates:
How to find elements on a specific branch in multiple VOBs:
cleartool find -avobs -element "brtype(branch)" -print