Resolve Conflicts in Projects Using System Composer Three-Way Merge Tool

Open Live Script

This example shows how to use the System Composer Three-Way Merge Tool to investigate and resolve conflicts in System Composer™ architecture models.

In this example, the RobotArchitectureProject project is under Git™ source control with conflicting and non-conflicting changes. The Three-Way Merge tool automatically merges non-conflicting changes before you open the merge report. This example demonstrates how to:

Review the automatic merge choices.
Apply your merge choices to the target file.
Decide how to resolve any remaining conflicts.

After you resolve the conflicts, you can commit the resolved architecture to source control.

System Composer Architecture Changes and Conflicts

The RobotArchitectureProject project is under Git source control. When you attempt to merge the changes of a colleague on the main Git branch into your taskBranch branch, the operation results in conflicts.

To resolve the conflicts using the Three-Way Merge tool, examine your local file (Mine), the conflicting revision (Theirs), and the common ancestor of these two files (Base).

Theirs - Your colleague updated the Motion component and updated the query used in the Component View view.
Mine - You updated the name of the Motion component, added a new property to the simpleProfile.sysConnector stereotype, and updated the query in the Component View view.

Open System Composer Three-Way Merge Tool

After opening the project, in the project Files view, look for conflicted files. Observe that the RobotArchitecture file shows a red warning icon in the Git column, which indicates at least one conflict.

To see a detailed report of conflicts, right-click the RobotArchitecture file and select View Conflicts.

Project View of the robot architecture project showing a conflict with the Robot Architecture model file.

View Changes

The Three-Way Merge tool shows the changes to the two System Composer architectures that cause this file conflict.

The Theirs , Base , and Mine trees show the differences between the conflicting revision (Theirs ) , your revision (Mine ), and the base ancestor (Base ) of these files.
The Target tree shows the file into which you merge changes. The tool replaces your local file when you click Accept & Close.
The summary table in the bottom right corner shows that the merge tool automatically resolved non-conflicting differences. The table also shows that you must resolve the remaining changes.

Three-Way Merge tool report showing differences between Theirs, Base, and Mine revisions of the Robot Architecture model file.

To resolve the remaining changes:

Examine a difference by clicking a row in one of the trees. The merge tool displays the change for each model in an editor, for example, the System Composer canvas, to the right of the Three-Way Merge window.
On the Merge tab, in the Highlight section, choose the models to display by clicking Top Model or Bottom Model.

Resolve Conflicts

The merge tool automatically merges non-conflicted differences before opening the Three-Way Merge report. In this example, 26 differences were already merged.

The merge tool cannot automatically resolve the conflicted differences. You must choose which design to keep in the target file in the Target tree.

To resolve conflicts:

1. To navigate to the first conflict on the toolstrip, click Next.

Click the Next button to go to the next conflict or manual merge.

Examine the first change at the top of the Theirs tree by clicking the Motion Component row. This conflict is caused by the change of the component name. You can adjust the automatic choices using the radio buttons in the Target tree. You can review and adjust all automatic merge choices.

2. To resolve the component name change difference in targetFile, in the Target tree, select the Mine column for Architecture Property Name and Simulink Property Name.

A conflict with the Architecture Property Name and the Simulink Property Name. In the tree, the Mine changes are selected with the radio buttons.

3. On the toolstrip, click Next to review the next conflict. The Component View is conflicted because you and your colleague changed the color and the query of the view.

For the Color parameter of the Component View, you can resolve the issue by selecting the Base change for Color to accept the default color for the view.
For the Component Selection Query parameter of the Component View, you can resolve the issue by selecting the Theirs change for Component Selection Query to accept the query your colleague used in Component View view.

4. On the toolstrip, click Next to navigate to the next conflict. The Motion Component is conflicted in the Component View because you and your colleague changed the component name of the Motion component and this change propagated to the view.

To stay consistent with the change you selected in step 2, select the Mine change for Architecture Property Name and Simulink Property Name to keep Motion Trajectory as the name of the component.

5. Check the summary table to verify you resolved all conflicts.

In this example, the summary table shows that you have successfully resolved all conflicts.

If you resolve all conflicts in the current view but the summary table title indicates that you have remaining changes, disable the filters to view and resolve the remaining conflicts. On the Merge tab, in the Filter section, turn the filters off.

Accept Changes

1. After you resolve all filtered and unfiltered changes, click Accept & Close. The merge tool closes the report and the models, accepts the merge result in targetFile, and marks the conflict as resolved in the source control tool.

2. Before you commit the resolved model file to source control, perform a final review by comparing the merge changes against the current branch.

In the project Files view, right-click the model and select Compare > Compare to Ancestor.

Select Compare and then Compare to Ancestor.