RTC Merging Approach
Hi Team,
|
Accepted answer
Ralph Schoon (63.5k●3●36●46)
| answered May 10 '17, 7:46 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Please read some of the articles https://jazz.net/library/#sort=pubDate&project=rational-team-concert&tag=SCM
Especially
Provide a version number in questions as there are changes.
In general merge only makes sense in the context of conflicting differences.
If there are no conflicting changes, there is no merge. Changes are on component level. If streams have no overlap at the component level, there is never a conflict and you can just deliver/accept.
In RTC you use repository workspaces to do changes. You check in changes into the workspace. You deliver changes into the stream and you accept incoming changes.
You use flow targets to integrate across streams, doing accept, merge, deliver of merged changes. Conflicts have to be resolved on repository workspace level. It is possible to deliver from one stream to another, if there are no changes.
Assuming you don't change code in production there should be no reason for a conflict, so no merge needed.
Amit Kumar selected this answer as the correct answer
|
2 other answers
Geoffrey Clemm (30.1k●3●30●35)
| answered May 10 '17, 2:44 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited May 10 '17, 2:56 p.m. In general, merging (manual or automatic) is only supported between two versions of the same artifact in the same component. This is true for any merge (whether between two streams, or between a change-set and a stream).
|
Can these merge be automated ? I mean, any scripts which we can schedule which can change the flow targets and do auto merge at the scheduled time? If so, then how conflicts which required manual merge will be taken care ?
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.