Delivering in RTC when we have conflicts in "Incoming"
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
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
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" .
@Ralph Schoon, Can you please help here. thanks
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.
Comments
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.