Version Control

Introduction

Version Control allows you to manage your app development in two ways:

• Firstly, it allows you to store (commit) the current revision of your model and all its resources. You give it an identifier so that you can get that revision again and share it with other team members.
• Secondly, it allows work to take place on multiple development lines so that several different features can be worked on at once. These development lines can then be merged back together so that your main line contains all the completed features that have been worked on separately.

Version control in Mendix is built on top Git. The concepts will be familiar to seasoned users of these version control systems (VCS). Mendix simplifies the VCS commands by building them into Studio Pro and the Mendix Portal.

Concepts

Team Server

Team Server is where all the committed versions of Mendix apps are stored. If you commit a revision of an app, it is stored on the Team Server.

To commit to the Team Server you will need to have a role in the app which allows you to edit the app. For more information, see the Team Roles section App Roles.

For more information on the Team Server and technologies involved, see Version Control FAQ.

Repository

Within the Team Server each app is stored in a repository. This repository contains all the committed revisions for the Branches of the app.

Revision

A revision is the version of your app at a moment in time, stored on the Team Server.

Each revision of your app is given a unique alphanumeric identifier which enables you to find it in future. A new revision is created from Studio Pro when the app is committed to the repository.

Working Copy

A working copy is the version of your app which is currently being worked on in Studio Pro. There is one working copy for each development line of the app. This model is held locally, on each computer where development work is taking place.

Merge

Merging is the action of taking one revision of an app and applying the differences which have been made in a different revision. See the Merging Branches section for more information.

If any of the differences cannot be applied, then there is a conflict.

Conflict

A conflict occurs when two versions of the app cannot be combined automatically. This happens when the same document has been changed in a Studio Pro working copy and a committed revision and these changes cannot be reconciled. These are some examples:

• The properties of a widget are changed in the revision and the working copy but to different settings
• A document is moved or deleted in the revision but has been changed in a different way in the working copy

When a conflict occurs, a developer has to intervene to decide how it should be resolved before it can be committed to the Team Server as a new revision.

Pull

Pulling is the action, invoked in Studio Pro, which gets the latest revision of the current development line from the repository and merges the differences into the current working copy.

Commit/Push

Committing is the action, invoked in Studio Pro, of creating a set of changes and pushing all your changes to the repository and making a new revision. It is possible to store the committed data in a local repository, but not yet push it to the central repository.

If there are no conflicts, the changes are then sent to the repository to make a new revision.

Development Line

Development of an app is done in a development line where a set of related changes is made. There are two types of development lines: the main line and branch lines.

Main Line

The main line is the initial development line for the app and is usually kept as the version which will be deployed to the production environment. Simple apps, and apps which do not require a high degree of collaboration, may only have a main line.

Branch Line

A branch line is a way of making an independent set of changes which can be tested away from the main line.

See the Branches section below for more information on how branch lines can be used.

Tag

A Tag is a way of identifying a commit in addition to the revision number. It is specified by the developer and has four parts:

• Major: used to identify significant new functionality, a new user interface, or other important change
• Minor: used to identify new functionality which augments the main function of the app
• Patch: used to identify a fix to an error in a previously-released app
• Revision: this is added automatically and is the revision number of the commit

Repository Service

The Repository Service manages communication between Studio Pro and other supporting services (for example, Team Server). The developer will not generally be aware that they are communicating via the Repository Service.

Mendix MPR Storage

An app modeled in Mendix is stored in an .mpr file, a database that contains data on all documents, such as microflows, workflows, pages. Studio Pro or the mx Command-Line Tool is required to inspect changes in the .mpr.

Branches

With more complex apps, you may want to manage your code in a more sophisticated way. For example, you may want to develop new features separately from the currently deployed version of your app so that you can fix any bugs without having to release all the new features. This is done using Branch Lines.

If you are already familiar with using branches, you can check the Branching Best-Practices section of Using Version Control in Studio Pro for advice on how to use branches when developing your Mendix app.

Main Line

All apps are developed along the main line. Here you have all development happening along a single line, with all changes built upon the previous revision:

Branch Line

When you add a branch line, you take a copy of an existing revision and work separately on that copy. Changes made to one branch do not impact any other branches.

In Mendix each commit within a repository is given a unique identifier.

Merging Branches

You may have a branch line which will continue independently and never need to be combined with any other development lines. For example, you may create a branch for a particular release of your app and only ever use it to fix bugs in that release.

On the other hand, you may want to add the features from one branch line into another development line. These are two cases for doing this:

• You develop new features in a branch line and want to include them in your main development line
• You want to take advantage of a bug fix which was made on another branch line

You can merge a specific revision of a branch line into your current working copy. If, for example, you were working on the main line updated to revision 6, you can merge revision 5 from another branch line into your working copy. Then you can commit the result to create revision 7. If you want to merge several different committed changes from a branch, you will need to select a range of revisions which includes all the changes.

There may be conflicts during the merge, and these will have to be resolved before you can commit the changes to your app.

Note that errors can be introduced by the merge process even if no conflicts are identified during the merge. Errors are inconsistencies which are flagged in Studio Pro and will prevent the app from being deployed. They could lead to a revision not being deployable, so it is important to check for errors after you have done a merge.

Documents in This Category