When you and other developers work in the same module and change the same elements, the OutSystems Platform cannot automatically merge the work for you. This is because the Platform finds changes in the same elements and cannot choose which one to publish. It's called a conflict and you have to resolve it manually, choosing which changes to publish.

Because conflicts happen when developers work on the same elements in the same module at the same time, it is advisable to plan the work ahead to distribute it well and avoid overlapped work and, consequently, conflicts.

The image above illustrates a situation of conflicts:

  1. The other developer opens version 4 of the module in his development environment. He starts developing;
  2. You open version 4 of the module in your development environment. You start developing;
  3. The other developer publishes his changes;
  4. You publish your changes:
    1. The OutSystems Platform determines that there are changes to be merged based on the version from where both started developing (V4);
    2. The Modified Version Detected window is displayed and you choose Merge and Publish;
    3. There are conflicts because you have changed some elements that the other developer also changed.
    4. The OutSystems Platform displays the Compare and Merge window. Selects the non-conflicting changes for you, but you have to decide which conflicting changes you want to keep.

Resolving a Conflict

In a conflict you have to choose between publishing your changes or the changes of the other developer. Normally, you keep the other developer's changes because you know what you did and you can replicate it. However, you can always discuss it with the team and decide which changes to keep.


As an example, imagine a Contacts application with two developers working on it: Matt Jones and John Baker.

The application has the following:

Each developer has to do the following:

Each one opens the module locally in development environment and starts working:

  1. Matt publishes his changes first;
  2. When John publishes his changes the Modified Version Detected window is displayed to him. It informs John that Matt Jones has already published a changed version of the module.

  1. In this case, when John clicks on Merge and Publish button, the Compare and Merge window is shown to resolve conflicts.

On the left hand side John has his changes and on the right hand side changes published by Matt Jones.

The changes highlighted in red are changes with conflicts. Both John and Matt have changed the screen to list contacts.

The changes highlighted in light blue mean that they are changes without conflicts. They and are automatically selected for merging.

  1. Now, John has to decide which changes to keep:

John double-clicks on the Contact_List screen to look into it.

Using the next difference button, John browses through all differences on the screen.

He realizes that Matt has changed the contacts list screen a lot.

He decides to keep Matt's changes and then add his own afterwards.

  1. John presses the Merge button to merge his changes and bring Matt's changes.
  2. He redoes his changes to the contacts list screen and publishes the work again. This time the module is published without the need of more merges, because he already has Matt's version in his module.

See Also

About Working in Teams | Merge and Publish | Compare and Merge | Elements Checkable for Merge