1

Often when I'm delivering activities for a build, I get an issue where one or two activities have dependencies on other activities that are not yet ready to be deployed.

What I want to do in most of these situations is force a merge between the two changes and deploy the stream, so that any changes in development that are lost during merge can be recovered.

What happens instead is that ClearCase forces me to move these changes to a new activity and include the activity if I want to make the delivery at all.

I have heard that I can render a branch obsolete - which would be satisfactory in some cases, but occasionally there are changes I might want to include in the deployment - is there any way for me to force a merge between two changes before making a deployment?

Zibbobz
  • 725
  • 1
  • 15
  • 41

2 Answers2

1

Sometimes, UCM doesn't let you make a deliver because of "linked" activities, that is because a previous deliver has created a timeline which made those activities linked (meaning you can no long er deliver one without the other)

In those instances, you still can merge any activity you want in a non-UCM fashion with cleartool findmerge: see "How to merge changes from a specific UCM activity from one ClearCase stream to another" for a complete example.

Then later, you will make your deliver (with all activities from the source stream).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

Adding on to @VonC's answer...

There are a couple of ways that you can wind up with activities linked together:

  1. Version dependency: Activity A has versions 1,2,&3 of foo.c Activity B has version 4 of foo.c. You can sometimes also have "1 & 3" and "2 & 4"
  2. Baseline Dependency: Activities A and B were delivered in the same deliver operation from Stream X to sibling stream Y. From that time forward, A&B have to be delivered together since they are in the same "deliverbl" baseline.

Number 1 can be changed by rearranging the changesets using 

cleartool chacct -fcsets {Activity X} -tcsets {activity Z} foo.c

Number 2 is pretty much set in stone...

Brian Cowan
  • 1,048
  • 6
  • 7