Clearcase UCM: Does a merge operation create any dependencies between branches

Question

Hi,

The question may be not very clear as I'm not looking for a solution of a problem but rather seeking to avoid possible problems in the future.

Say we have projects A B and C, B and C are based on different baselines of A. Is it ok to do merges between B and C in both directions from B to C and vice versa, wouldn't it create problems later on?

In my particular situation I have versions merged from A to B, from B to C and now I want to merge from C to B. A in the trunk, C is installation specific and B is customer-specific. We will eventually abandon C when the customer has a newer build deployed. But there's a situation now (by mistake) that some changes are merged from A to C bypassing B. The changes should have gone A -> B -> C. The problem is that some merges from A to C were nontrivial merges and I don't want to repeat the work of manual merging from A to B. It seems to be easier to just merge from C to B for this versions. Is it ok?

Thanks!

Answer 1

B and C are based on different baselines of A. Is it ok to do merges between B and C in both directions from B to C and vice versa

What you are describing is called sideway merges and you can see (following the link) that they comes with a price: merges will likely be non-trivial at some point.

In your case, though, if B did not touch the files that were merged (with non-trivial resolution) from A to C, then merges from A to B should be trivial (simple copy of the version stored in A on top of the one in B)
By merging from V to B, you would include potential modifications from C which you would have to eliminate during that merge.

In a more general way, you can rebase/deliver in whatever order you want, but some workflow can be rigged to produced non-trivial merges if they follow a "sideway" pattern as the previous link illustrate.