Workspace conflicts

Introduction

While working on an app with a team, multiple developers will be working and committing on the same branch. When you have a workspace of a branch, and someone else commits changes to that branch, your workspace will become outdated as it will not contain those changes.

You can only commit if your workspace is at the latest revision of the branch. You will often need to update before committing. See the illustration below.

Updating your workspace

Follow these steps to update your workspace.

Step	Action
1	Go to the Superadmin Workspaces tab.
2	Select the workspace you want to update from the Workspace drop-down list.
3	Click on the Workspace menu icon and select Update....

Result

Updating your workspace will have one of the following possible results.

1. Your workspace was already up to date.

   No-one else has made changes to the branch you are working on.

2. Your workspace was successfully updated.

   You can now also see the changes that other developers made in the meantime.

3. Update successful with Warning.

   An update has been done but there are still unresolved conflicts due to changes other developers made in the branch. Information is provided on how many commits have been updated.

4. The update failed.

   • Conflict in non-application file.

     • Local modifications in non-application files conflict with changes made by someone else.

   • Add/add or delete/modify on file.

     • A file with local modifications was deleted by someone else.
     • You deleted a file another developer modified.
     • You created a new file with the same name as a new file created by another developer.

Conflicts

When updating while your workspace contains local modifications, it is possible that your changes conflict with changes committed by another developer. In this case, your app will contain conflicts that need to be resolved before you can commit.

Note: Try to avoid conflicts by not working on the same charts, tables, attributes, filters, etc simultaneously.

If your app contains conflicts, this will be visible in the workspace. See illustration below.

Conflicts in text files

When a conflict occurs in a file other than the .mvp file while updating athe workspace, the default Git merge conflict markers placed in the text file (>>>>>>>>>>>>). This enables you to resolve the conflicts after the update has finished.

Note: All file types that can be opened in a text editor are considered as text files. For example .Json, .txt, .csv, etc.

Resolving conflicts

After resolving all conflicts, it is possible to commit your changes. The following options are available to resolve conflicts.

Option	Dsecription
Resolve as mine	Pick your local modifications over the changes someone else made. Note: the version number will be set to 2, which will be a local modification you still have to commit.
Resolve as theirs	Pick the changes that another developer has made. Note: the version number will be set on 1, and there will not be any local modifications.
Mark as resolved	Ignore the conflict. However, you must investigate the current state and possibly make changes first to make sure it is correct. You are responsible for ensuring the application is in the correct state.