This week we are welcoming guest blogger Tim Hosey from the Simulink Project development team.

Introduction

In this blog post I will highlight how Simulink Project can be used to manage conflicts that occur when two users submit changes to the same Simulink model using a source control tool.

A conflict arises when two users make changes to the same file. The first user to submit their changes to the source control system experiences no problem, but the second user’s changes are considered to be in conflict with the first user’s changes; so the source control tool prevents the second user from committing their file until they have merged their changes into the first user’s version of the file.

Environment set up

In order to show how conflict resolution can be performed with Simulink Project I have set up a modified version of our Airframe demo.

I created two working copies called demo1 and demo2 which are checked out from an SVN repository created by running the above demo. User 1 will use the folder demo1 and user 2 will use the folder demo 2.

Here is a screenshot of what the project looks like when user 1 opens their copy of the project in the working copy demo1.

Binary case

I have set up my SVN config file to consider slx files binary, see our documentation about how to set up SVN source control.

The project contains a model called vertical_channel.slx which looks like this:

User 1 modifies this model to change the sign of both the sum block and the feedback gain, so that it now looks like this:

User 1 then commits his changes using the modified files view.

This trivial change was easy to make and commit to the SVN repository, but as we are about to see when user 2 makes a change to his copy of this file, submitting the change is going to be much more difficult.

User 2 hasn’t performed any update so his project looks the same as user 1’s project before he made his change.

User 2 opens the vertical channel model and adds a scope to his model so that it looks like this:

When user 2 tries to commit they get the following error:

This error tells him that he doesn’t have the latest version of vertical_channel.slx so he can’t commit his changes to it. To get the latest version he performs an update. This causes a problem because the changes in his working copy conflict with the changes made between the version of the file that has and the latest version in the repository submitted by user 1. User 2’s change is now in conflict with the change submitted to the repository by user 1. The project marks this file as conflicted user 2’s project.

Because we registered .slx files as binary with SVN, the SVN update did not attempt change the content of the file vertical_channel.slx, it still contains user 2’s addition of the scope to the original model.

User 2 can use Simulink Project to resolve the conflict as follows:

1. First the user needs to view the conflict, he can do this by right clicking on the file and selecting ‘view conflicts’ in the Simulink Project’s file context menu. If Simulink Report Generator is installed a Simulink XML comparison will be used to show the conflicts between user 1’s version of the model and user 2’s version.
   
   
   
2. User 2 can then easily select and merge the changes from user 1 that they want to include in their version of the file.
   
   
   
3. Once user 2 is happy with the resultant merged file he can right click on the file in the project’s file context menu and select ‘mark conflict resolved’. Now the conflicted file is marked as modified and can be submitted to the SVN repository.
   
   
   

When user 1 performs an update he now gets the merged model in his working copy:

Now it's your turn

Do you often need to merge Simulink models? Let us know by leaving a comment here.