Version control

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 global merge driver setting: registers the merge driver for MPS models in the global Git settings, 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.

• Git file attributes for 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.

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.

tip

The .mps/workspace.xml file that stores the layout of the MPS windows is excluded automatically by MPS.

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:

workspace.xml
junitvmwatcher*.properties
build.properties

# generated java classes and java source files
#   manually add any custom artifacts that can't be generated from the models
classes_gen
source_gen
source_gen.caches

# generated test code and test results
test_gen
test_gen.caches
TEST-*.xml
junit*.properties