It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×6,034
×4,321

question asked: Jul 16 '17, 7:08 a.m.
question was seen: 3,375 times
last updated: Jul 24 '17, 9:02 a.m.

Related questions

Delivering in RTC when we have conflicts in "Incoming"

0
Amit Kumar (19●5●14) | asked Jul 16 '17, 7:08 a.m.

I have some conflicting change sets in "Incoming " . So, Can I deliver the change sets  which is in "outgoing" of my Workspace , without resolving the incoming conflicts "Change sets " ? Is there any pre-condition  set in any configuration which can be customized to allow delivering of change sets even if we have "conflicts" in "Incoming" ?




2 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Luca Martinucci (1.0k●3●97●112) | answered Jul 16 '17, 8:58 a.m.

For all I know, RTC does not prevent you from delivering when there are conflicts.
Simply, you are prompted by RTC to resolve them during the delivery
The best practice is to resolve them in your development environment (your repository workspace) rather than in the integration environment (the target stream).
So, my advice is to accept the incoming changes before delivering your changes: this way, you will resolve any conflict during the accept phase, and then deliver a new set of unconflicting changes, that includes the "merge" change sets.

Comments
Amit Kumar commented Jul 16 '17, 10:10 a.m. | edited Jul 23 '17, 9:33 a.m.

Thanks Luca.

Actually , I am in a situation where by mistake some one has delivered wrong "Component baseline" to my stream.

Let me explain this :
I have 2 streams, A and B. which has same component "C". Now,  I needed to merge Stream A from  Stream B.
So, when I change Incoming flow target of my Stream A Workspace ( to  accept the change sets which were delivered in Stream B , for merging)  . that "Component Baseline" of Stream B ( which was wrongly delivered on server on Stream B by my peer ) also comes in the "Incoming " . and If I accepts this "component Baseline" it replaces my Component of Stream "A" .

Is there any way to discard the incomings ( particularly of this "component Baseline") , so that I can only accepts the incoming change sets of Stream B, and discard the "component baseline" (which is showing in "Incoming" )

What I was trying above was to accept the change sets and deliver in Stream A. and then again accept the "component baseline" and then deliver in any other dummy stream, so that , my stream A at least don't get corrup due to this wrong "component baseline" .

Amit Kumar commented Jul 16 '17, 11:43 p.m.

@Ralph Schoon, Can you please help here. thanks

0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Jul 23 '17, 9:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

 RTC will never allow you to deliver change sets to a stream that would produce a conflict in that stream.   This would make the stream unusable, since the version selected for the files/directories in conflict would be ambiguous.  

All conflict resolution (such as merging) must be done in a repository workspace.   So accept whatever changes you want from Stream B (you don't have to accept all of them), do whatever merging is required, and deliver the resulting (non-conflicting) change sets to Stream A.

WRT your scenario, note that a baseline never contains any changes other than those of the change sets that it contains.   A baseline is just a "marker" in the change set history.  So when you say "accept the change sets, but not the baseline", you are not avoiding any changes that way ... you are just avoiding that "marker".   To tell whether you have accepted all of the change sets in a given incoming baseline, just open that baseline in the Incoming changes folder ... if there are no change sets under that baseline, then you already have all the change sets from that baseline in your workspace.
 

Comments
Kim Soederhamn commented Jul 24 '17, 9:02 a.m.

yeah you should basically make sure you deliver as often as possible to limit the amount of conflicts. If you discover you for some reason do not need a change at all in your common truth (Eg your stream) you should deliver a patch that removes this change or with the latest version of RTC(6.0.4) roll it back and then you can proceed delivering your own changes.

Your answer

Register or to post 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.