How to automatically deliver changesets by skipping the files which have conflict
We are using a solution mentioned in the article https://jazz.net/library/article/529/ under section Delivering Change Sets Automatically Between Streams to sync up development stream from production stream.
We are able to deliver changesets automatically in case there are no conflicts.
However we want a way where we can skip the changesets in conflict and deliver only those without having conflict automatically.
Could you please let us know a way to handle this.
3 answers
Hi Shubhada.
The problem you will encounter is that if there is a conflict, and there are change sets stacked up for a source member, that conflict must be resolved before any others will be able to be delivered, otherwise, you would get a gap.
I'm guessing you are seeing this on specific components, where if there is a conflict on a component, it will stack up change sets until you resolve them.
A long term strategy might be to break the components into smaller components (knowing your environment, I'd say that's going to be hard and a long term goal at best).
Another idea is if you have copybooks that are used by many members, you could separate those into their own component, and nest them under the components that would use them. Look at this article on subcomponents: https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.6/com.ibm.team.scm.doc/topics/t_component_add_remove.html
Lastly, you could also split streams into more up streams (i.e. indigo and navy flow into the blue stream). That may help developers work a bit more independently and allow team leads to focus on just the blue stream for conflict resolutions.
The only way to solve this is to make sure there are no conflicts and gaps introduced.
Conflicts can only avoided when only one person works on a file. Otherwise you have to accept and merge them.
Gaps can be avoided by using a preconditon for checkin.
Gaps are introduced if you change the same file in different changes sets together with other files.
E.g. File f1, f2, f3.
Change CS1: F1, F2
Change CS2: F1, F3
You can not deliver CS2 without delivering CS1 before.
A custom checkin precondition can prevent checking in changes to multiple files into the same change set and help avoiding this situation. Customers have implemented this kind of stuff to make cherry picking during integration possible.