Main version control shortcuts

VCS menu

VCS Add-ons

When you first import a project to MPS from a version control, or add VCS mapping for an existing project, MPS suggests installing the so-called VCS Add-ons (they can also be installed later from the main menu: Version Control | Install MPS VCS Add-ons).

VCS Add-ons are special hooks or merge drivers for Subversion and Git that override the native merging mechanism for specific types of files. They determine the merging procedure for model files (*.mps) and generated model caches (dependencies, generated and trace.info files). Every time you perform a VCS-related operation (like merge or rebase branches), these hooks are invoked.

For models, they read their XML content and tries merging the changes on a high level, in "model" terms instead of simply merging lines of an .xml file which may lead to invalid markup. Sometimes, models cannot be merged automatically, and then they stay in the conflicting state and can be merged manually. For example, id conflicts may occur during the merge when a model ends up with more than one node with the same id after all non-conflicting changes have been applied. In this situation, no automatic merge is performed because it may lead to issues with nodes references which are then hard to identify. You need to inspect merge results and manually resolve such conflicts.

For model caches, merge drivers work differently. Generator dependencies (generated files) and debugger trace caches (trace.info files) are cleared after the merge, so you will need to regenerate the corresponding models. Java dependencies (dependencies files) used on compilation are merged using a simple union algorithm which makes compilation possible after the merge.

There are several types of VCS Add-ons.

• Git global autocrlf setting: forces Git to store text files with the standard Unix line endings (LF) in the remote repository, while text files in the working copy use local system-dependent line endings. This is handy if your teammates use different operating systems that have different line endings (Windows and Unix).

• Git merge driver and setting for N out of M repositories: registers the merge driver for MPS models in the Git setting for VCS roots that still do not have it installed, so that they can be referred to in the .gitattributes files. It only maps the merge driver name with the path to the actual merge driver command. The number N indicates how many repositories need to have the MPS merge driver enabled out of the total number of M repositories that are part of the project.

• Git file attributes for N repositories: enables the MPS merge driver for specific file types (*.mps, trace.info, etc). It creates a file listing all existing file types so that the merge driver is aware of them. It is recommended to keep this file under version control, as the configuration will be shared among your team members. The number N indicates how many repositories should have the MPS merge driver enabled for MPS-specific files.

Ignore files

There are two strategies for storing the MPS models in a VCS:

• To put only the essential MPS project configuration files (the .mps folder except for the workspace.xml file) and the project sources (the model files, such as msd, mpl and mps file types) under version control.

• To additionally also include the generated code.

With the generated code included in VCS you must remember to regenerate your models before you commit the changes.

For example, when using Git, a typical .gitignore file that excludes workspace.xml, the generated files as well as the typical by-products of running tests may look like this: