Reputation: 13717
I am trying to merge a single proc from a branch Nov12
to main
. After searching in this reference I found the following should merge a copy from the branch to the main
Merge version 1 on the branch into the "latest" version in the "main" branch:
ct merge -to new_update.sql -insert -version /main/Nov12/1
After running this I got the output as
Trivial merge: "new_update.sql" is same as base "/home/mtk/ct/new_update.sql@@/main/Nov12/0".
Copying "/home/mtk/ct/new_update.sql @@/main/Nov12/1" to output file.
Output of merge is in "new_update.sql.merge".
the new_update.sql.merge
contains the complete proc on local disk, it's not in the clearcase version control. I did a ct lsh
to verify this.
I wanted it should have created a new version on the main and placed the updated copy into it i.e. /main/9 which not yet exists. The latest /main
version is 8.
So, how to merge a single proc. Do we need to checkout a copy from the main and then run the above command. Please let me know, I am not clear on this. I need a command line solution for this, as graphical alternative is not available.
Upvotes: 1
Views: 2769
Reputation: 755094
I think the trouble is that you didn't specify where the output was to go, so it was put in the file new_update.sql.merge
, assuming that the current view has a cspec set to your target branch, /main
. (If your view doesn't reference the /main
branch, you're merging in the wrong view.) You can now do:
mv new_update.sql.merge new_update.sql
and then make the check-in, assuming that either you or ClearCase did the necessary checkout.
That isn't the way I customarily do merges — but that isn't to say it is invalid. The mechanism I use is ct findmerge
and then run the commands from the log file. I'd have two views, one with a cspec for the Nov12 branch (the view tag might be nov12
), the other (the current view) with a cspec for the main branch.
ct findmerge -ftag nov12 new_update.sql
The output might include lines like:
Needs Merge "./samizdat.c" [(automatic) to /main/XYZ.1.70/0 from /main/XYZ.1.70
/TEMP.bug233636.jleffler/1 (base also /main/XYZ.1.70/0)]
This will generate a log file with a name like:
findmerge.log.2012-11-27T23:12:43-08:00
The contents of the file is commands like:
cleartool findmerge ./samizdat.c -fver /main/XYZ.1.70/TEMP.bug233636.jleffler/1 -log /dev/null -merge -cqe
The -merge
means 'non-graphical merge' (-gmerge
for graphical); the -cqe
means 'query for comments for each check-out' (I always replace that with -c "Bug 233636: Brief title for bug"
).
I doubt if it is the quickest possible way of doing business, but it does work for me. I've disguised file and branch names, but assuming I get my review approved, that's (more or less) how I'll be doing a merge and check-in of about 20 files for a mini (micro?) feature. I have cover scripts to drive a lot of this stuff, so my command sequence will actually be:
fmp -l log 233636 /vobs/project/ /vobs/auxilliary
fmm log
ct ci -c 'Bug 233636: Brief title for bug' $(ct lsco -avo -cvi -s)
The fmp
(find merge and print) script runs the first findmerge
with the output going to the file log
. The fmm
(find merge and merge) script does the actual merging, and automatically provides the last check-in message for the files to be merged. The last line does the check-in with my chosen comment (ct
is an alias for cleartool
), overriding the comment provided by fmm
.
Upvotes: 2
Reputation: 1330082
You need to be in a view set to create version on /main
.
Instead, your merge wanted to create a version on Nov12
The page "To merge selective versions from a subbranch" details the merge you are using:
cleartool merge [ -graphical ] -to target-path -insert contributor-version-selector [contributor-version-selector]
But it also requires to check out the target version first.
That means that, even before your merge, you should see in the version tree a version created after your /main/8
one.
So try again your merge in the right target view, the one made to make new version on /main
.
Upvotes: 2