Pregunta

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.

¿Fue útil?

Solución

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.

Otros consejos

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.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top