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.
Related
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.
I want to check with a batch file if a certain element is already existent in Clearcase, or if I still have to add it.
How can I put this into a conditional statement?
Like:
if cleartool exists myFileName do myaction
else doOtherAction
You need to build a function which returns true or false depending on the element full name being part of the ClearCase view elements or not.
Then you can call that function from your if... else... statement.
Here are various commands that your function could use in order to determine if a file is a ClearCase element (meaning already added to source control) or not:
You can start by using the result of cleartool ls -l: if its output includes view-private object, it isn't added to source control yet.
cmd-context ls -long
version Makefile##\main\3 Rule: element * \main\LATEST
view private object bug.report
version cm_add.c##\main\0 Rule: element * \main\LATEST
derived object (unshared) hello##2007-03-24T11:32.418
version hello.h##\main\CHECKEDOUT from \main\2
Rule: element * CHECKEDOUT
Here 'bug.report' isn't added yet.
See more at "About view-private objects".
I already recommended that approach for a previous question using C#: "c# How to determine if a file is in ClearCase?".
Another approach is to use cleartool describe, which would trigger an error if the element described is a private one.
As mentioned in the technote "How to list view-private files in a view in Rational ClearCase", the command cleartool lsprivate works only in dynamic views, not in snapshot views.
For snapshot view, you can use: cleartool ls -r -view_only
Another approach is to use cleartool find, as in "Clearcase: How do I check if an element has a version on the trunk that was created after I branched off from the trunk?"
The following DOS batch file will add a file to ClearCase if it's not in there yet. Works in both dynamic and snapshot views.
#ECHO OFF
cleartool ls -l %1 | FIND "view private object"
IF %ERRORLEVEL% == 1 GOTO END
cleartool co -nc .
cleartool mkelem -nc -ci %1
cleartool ci -nc .
:END
You may want to add suitable comments instead of using the -nc switch.
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 could not find the proper command to apply a label to files which are in my current view. I have tried the following command:
cleartool mklabel -r TEST_LABEL /vob/test/a
However, the problem is that this command will apply the "Test_Label" label to every files in the "vob/test/a" directories regardless of whether the files are in my current view.
Is there any command to apply label only to the files listed in my current view?
cleartool mklabel -r(ecurse) LABEL_NAME <directory name>
This command will apply LABEL_NAME to all files in folder and below of your view, you can just go to that directory,then type following command to create and apply label
> cd /vob/test/a
> cleartool mklbtype –nc TEST_LABEL
> cleartool mklabel -r TEST_LABEL .
The mklabel documentation state states, as to what version is labeled:
Processes the entire subtree of each pname that is a directory element (including pname itself). VOB symbolic links are not traversed during the recursive descent into the subtree.
One example mentions:
Attach that label to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory.
Now, if you want to be really sure of the versions actually labelled, one solution is to use a find command, combined with your mklabel:
cleartool find . -cview -exec "cleartool mklabel TEST_LABEL \"%CLEARCASE_XPN%\""
If you had already that label applied to incorrect version and want to move it:
cleartool find . -cview -exec "cleartool mklabel -replace TEST_LABEL \"%CLEARCASE_XPN%\""
That way, you can first list the versions involved:
cleartool find . -cview -print
And then, if you agree with the output, apply the mklabel through the -exec directive.
The OP user1096966 reports making it work with a cleartool ls, to be sure to select only element visible in the current view:
cleartool ls -r -vis
The is no '-exec' directive, so a pipe might be involved, as in (not tested, but you get the idea):
cleartool ls -r -vis -s -nxn | xargs cleartool mklabel -replace TEST_LABEL
The doco is really clear about what is being labelled, in fact the first example shown in doco states that exactly...current view objects are labelled by default & currently selected versions (i.e. if in your view then label it, else not.)
....extract below from doco below (note: context and command and that label-type-selector pname is the last parameter...left blank below because resident in working dir)...
Example:
•Create a label type named REL6. Attach that label to the version of the current directory selected by your view, and to the currently selected version of each element in and below the current directory.
cmd-context> mklbtype –nc REL6
Regards
Jim2
As title, could anyone of you give me a working instruction to solve that problem ?
thanks a lot!
If you only after checked-out files and you are in a dynamic view set to see only MY_BRANCH:
ct lsprivate -co .
(with '.' being the parent directory under which you want to find co files)
That command is recursive by default.
Your config spec would need to be
element * CHECKEDOUT
element * .../MY_BRANCH/LATEST
element -directory /main/LATEST
With checked-out files and directories in a snapshot or dynamic view, use indeed lsco, but knowing that command is not recursive by default. So I would recommend:
ct lsco -rec -brtype MY_BRANCH
$ ct lsco -brtype your-branch-type-selector
Start by having a look here : IBM ClearCase Command Reference : lscheckout
Then, as an example, try this...
If your branch was foo, and your are in the VOB you want to check, you can run
ct lsco -brtype foo
or
ct lsco -brtype brtype:foo