1

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.

mtk
  • 13,221
  • 16
  • 72
  • 112

2 Answers2

2

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.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • So, do I need to delete my answer because I'm just misleading? Or confusing? – Jonathan Leffler Nov 28 '12 at 07:31
  • @JonathanLeffler the key point of your answer is the same as mine: check your target view. The `findmerge` (especially with `-fver` option: the OP might not have set any tag) is a nice alternative, so I would like to see your answer stay. – VonC Nov 28 '12 at 07:35
  • @VonC You are correct. I am not in the correct view. Thanks that helped correctly. – mtk Nov 28 '12 at 08:03
2

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.

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
  • Whoa, I now understand why you are still in front of me in the query http://data.stackexchange.com/stackoverflow/query/8782/users-who-post-long-answers (use 5000 posts) ;) – VonC Nov 28 '12 at 07:33
  • And I don't think `findmerge` is required here. Yet, it is a valid alternative, so +1. – VonC Nov 28 '12 at 07:33
  • Oooh; I post longer posts on average than anyone else? And not very effectively, since my rep/character is lower than most. You'd best get busy typing another 1.3 MB of answer... (Interesting; the standard deviation on the length of my posts is larger than my average post!) – Jonathan Leffler Nov 28 '12 at 07:38
  • Yes, I have always found that query... fascinating ;) – VonC Nov 28 '12 at 07:40
  • You're correct that `findmerge` is probably not necessary. However, it is the way I always work because there is less chance of me missing one file in some sundry VOB when I've made changes in 6 directories in 3 VOBs. – Jonathan Leffler Nov 28 '12 at 07:40
  • I agree, and find that answer a good opportunity to document and illustrate the `findmerge` command. So, it is a good one. – VonC Nov 28 '12 at 07:42
  • Thanks for the detailed explanation :) I find this useful +1. – mtk Nov 28 '12 at 08:04