My first experience with collisions happened a couple of years ago when there was a transport within our repositories and one of my changes resulted in a collision. I received a mail requesting me to resolve the collision. I had no idea what collisions were and even less idea about why I was getting the mail. Thus began my journey into the world of collisions.
I did a lot of reading and a lot of learning from seniors and these gave me some idea about collisions. But I was never really sure. All I did when I had to resolve collisions was to “Accept Baseline Version” which worked fine most of the times but not always. The assumption was that the Baseline was always correct and if I lost any changes I would do them again. I never tried the option “Merge”. But when I came to know about how the “Merge” option works, it helped me resolve collisions better. I could choose between the changes I want from the Baseline and Changelist versions. It was a slow learning process. But collision is no longer a great mystery and I feel confident about resolving collisions.
This confidence is something which is lacking in a lot of developers and even customers. Here are some facts (which I know of) which might help in increasing the confidence –
1) Collisions do not indicate any problems / issues in the repository. It just indicates that the same development object has been changed in two different locations.
2) Customer-specific changes are not lost during upgrade. Collisions are a good thing in the sense that it avoids lose of customer-specific changes. Imagine a situation where “collisions” do not exist, you might find your customer-specific changes disappearing after each upgrade. Thank God for collisions!!!
3) Resolving collisions is not complex. It’s as simple as having a look at two versions of the same development object and choosing the changes you would like to keep from both the versions (in the “Merge” option)
So the next time you encounter collisions, enjoy the collision resolution process!!! Believe me, it’s easy.