Best practice for resolving changes in RTC: Deleviring vs Incoming Changes (resolving)
What is the best way for resolving changes in rtc. When developers are going to deliver their code in rtc they are receiving issues dealing with code being out of sync. What is the best practice for dealing with resolving changes (delivering code vs accepting incoming changes, etc)
Do developers need to accept incoming changes first before delivering their changes? (I understand this is a "depends" type of answers)
We are under the impression that we need to accept incoming changes before we can deliver our code. We are wary under this assumption as it can potentially overwrite all of our changes made UN our repository work space
Accepted answer
Hi Tony,
Resolving changes: always good to accept the changes before delivering the changes.
If you are trying to deliver the changes ( common code\files), when you have a incoming changes (common code\files) it will try to overwrite but you need to resolve the conflict changes and you should use the manual merging and deliver the changes.
Note: It will notify about the conflict or changes and ask for the action before it overwrites the code in RWS.
https://jazz.net/library/article/39
https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.scm.doc/topics/t_scm_conflict_content.html&scope=null
Resolving changes: always good to accept the changes before delivering the changes.
If you are trying to deliver the changes ( common code\files), when you have a incoming changes (common code\files) it will try to overwrite but you need to resolve the conflict changes and you should use the manual merging and deliver the changes.
Note: It will notify about the conflict or changes and ask for the action before it overwrites the code in RWS.
https://jazz.net/library/article/39
https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.team.scm.doc/topics/t_scm_conflict_content.html&scope=null