How does branch/merge in RTC relate to branch/merge in ClearCase?
Personally, I think the branching in ClearCase (streaming in RTC world) provided more straightforward/clear views to us, especially with the version tree (non-UCM model). RTC was developed possibly by referring ClearCase UCM model and does not provide version tree any more. Instead, change history with associated change sets is provided. Compared to clearcase version tree, that "change set tree" (change history view) is not easy to follow when multiple streams are involved. On the other hand, no more version history within a repository workspace (like a developer's dynamic or snapshot view). With the version tree, it is so easy for developers to do 3-way diff and merge changes based on different "branches".
Well, we have to move forward in the RTC world:-). I really hope Rational team can provide more clear picture/steps for doing branching/merging based on streams and repository workspace. The freedom of changing flow target in a repository workspace makes merge more tricky than ClearCase. Sometimes I got lost how the merge algebra in ClearCase can apply when flow target is switched while changes were already made in the repository workspace. Can RTC merger handle the right thing? I recall it did not for me when I managed the team's branch merges and certain files/directories were deleted instead of being kept in a new flow target (well, this was RTC 2.2).
One more thing, personally I like the findmerge tool in ClearCase better than the merger in RTC.
With all these many words, I really hope some experts in Rational team, who understand deeply the branching and merge in ClearCase (non-UCM or UCM model) and certainly also the streaming and accept of changes in RTC, can seriously review the proposal in https://jazz.net/forum/questions/92845/rtc-branching-and-merging-strategy and provide more detailed steps/procedure for doing "branching"/streaming with RTC, especially great if comparison with branching/merging in ClearCase can be provided.
BTW, the other lesson I learned was to use different dedicated certain repository workspaces with consistent flow targets for each to manage the merge/delivery. This may not be a must but at least makes me more comfortable and feel safer.
One answer
- The merge algorithm in RTC is logically the same as is found in ClearCase, i.e., given a configuration (stream, workspace) that selects a different version of a given file, find the common ancestor of the two versions, and then do a 3-way merge. Changing the "flow target" of a workspace is just RTC's way of letting you specify what branch (stream) you want to merge into your workspace (cleartool findmerge gives you the same flexibility). Note that ClearCase and RTC use a different common ancestor algorithm.
- If you prefer ClearCase's merge tool, you can specify it in the Eclipse Preferences section (in the External Compare Tools section). You will need to have the ClearCase client loaded onto your machine so that the ClearCase merge tooling is available.