Versioning with Git

Mendix 9 introduced Git versioning as an alternative to Subversion (SVN) versioning. Since then, the Git implementation in the Mendix platform has improved and become a suitable replacement for SVN.

Starting with Mendix 10, Git is the only option, which means that you will have to migrate existing projects from SVN to Git before you may upgrade. More information about that may be read in Kasja Maksymiak 's blog. Since her blog, it has also become possible to migrate those projects that are not migratable due to the limitations. You will, however, need to start fresh in Git and, for historical purposes, refer to an export of the SVN repository.?

For a more general overview of Git and Mendix, read Marius van der Knaap ’s blog post. His post is an excellent introduction based on the state of the Git implementation on the Mendix platform eight months ago.

Since then, a lot has improved. With the release of Mendix 10.18, resolving conflicts has become more logical, and migration is no longer blocking any project from moving on to Mendix 10.

Migration

Migrating from SVN to Git is required to upgrade your project to Mendix 10.?

To migrate, your app needs to conform to the following:

• The main line (‘main’) branch in the app is Studio Pro version 9.24.28 or above
• All branches in the app are Studio Pro version 9.12 or above
• Current version control is in Team Server SVN
• The size of the MPR file for the latest revision is smaller than 400 MB

The entire SVN repository should be smaller than 3.5 GB to migrate your history.

Only scrum master role users can start the migration.

With history

Migrating with history is very well explained by Kasja in her blog:

https://medium.com/postnl-engineering/mendix-svn-upgrade-to-github-b4be48d6510d?

Without history

If your app is ineligible for migration due to the size of the repository and all other prerequisites have been met, you may choose to migrate to Git without retaining your SVN repository history.

Remember that, in this case, you will only migrate the latest commit in the mainline of your repository to Git.?

After the migration, your project's scrum master users can download a full backup of the SVN repository.

Follow the steps listed in Kasja’s blog to start the migration, and the platform will guide you in migrating without history.

Committing

Local

Local commit will not push the changes to the remote repository. You can then push the changes manually to rebase or merge them with the changes on the remote repository.

Rebase vs Merge

While both accomplish similar results, there are differences we did not have to think about when using SVN versioning.

Merge

1. Merge integrates changes from one branch into another via a “merge commit.”??
2. It preserves the original commit history of both branches.??
3. The history can become “branchy” and include extra merge commits.??
4. It’s safer for collaborative branches, as it doesn’t rewrite history.??
5. Great for resolving conflicts and then committing to finalise the merge.??
6. It's ideal when you need a record of exactly when branches are combined.??
7. Sometimes, it leads to a cluttered log with many merge commits.??
8. It works well if your team values explicit branching events.??
9. Easy to understand: you see precisely how branches joined.

Rebase

1. Rebase “lifts” your local commits and replays them on top of another branch.??
2. This rewrites commit history for a cleaner, linear log.??
3. Fix conflicts and continue running rebase after resolving them.?
4. Requires caution: rewriting public history can disrupt others.??
5. Ideal for short-lived feature branches to keep them up-to-date.??
6. Produces a single, tidy timeline without merging commits.??
7. It's good when your team prefers minimal branching in the history.??

Rebase is a safe method, according to Mendix, but given this explanation, you might want to invest the extra time to use the Merge method.

Pulling changes

When pulling changes while you have local commit, you must choose which combine method you want to utilise. See the previous chapter for more details.

Branching

Branching is an excellent method to work in parallel on several features. Or to ensure that only fully tested/reviewed features end up in a release branch for release.

You may create/remove/switch branches from the Manage Branch Lines… option in the Version Control menu.

You can manage branches from any repo with Mendix apps. By default, the app that you currently have open will be selected.

Once it is time to merge the changes from a branch you can merge a specific commit or the full feature branch.

Make to merge changes while having the branch you want to merge open.

Merging conflicts

Merging conflicts after retrieving the changes from the remote repository will allow you to handle the conflicts more fine-grained.

While the changes are still shown textually, it is a great way to handle the conflicts on action level instead of having to replace the full microflow and redo either your changes or those from the remote repository.

You may handle conflicts from your Mendix model and files directly in Studio Pro.

Mendix model

Resolve the conflict using the server changes (remote repository) or local changes will mean you will lose one of the changes. Make sure to list what was changed before you make your choice in case you need to reapply parts.

Files

Private remote repository

When your organisation uses its own private Git repository, you must prepare your Studio Pro installation.?

First, open a project and go to preferences (Top menu > Edit > Preferences…). Then, go to Version Control> Git. Check Enable private version control with Git and fill in your Name and Email. Finally, save your preferences by clicking the OK button.

Your next step is to download the app from the private repository.

In the top menu, go to Version Control > Download from Version Control Server. In the popup, choose the Private Server option. Fill in the App repository address. And hit Connect.

After saving and hitting the OK button, you will be requested to sign in with your credentials to the private repository.

Choose the Project directory. From this moment forward, you will work against the private Git repository for this local working copy.

Settings

Some settings you might not know about yet but can be helpful depending on your situation.

To be found under Top menu > Edit > Preferences… > Version control > Git

Clone type

By default, this is set to Full, which will clone the entire history to your local working copy. This is required when you work offline and want to access the history, and it is not so much of an issue when you have a short history in a smaller repo. However, you might consider a Partial clone, which will only download the latest commit. This will significantly decrease the disk space and shorten the download time.?

Combine local and remote changes action

This specifies the default when pulling changes and combining them with your local changes.

Enable automatic fetching from a remote repository (enabled by default)

This mechanism fetches the changes pushed by others to the remote repository.?It also shows any local commits ready to be pushed to the remote repository.

The fetch interval in minutes determines the time between fetches for potential changes on the remote repository.

Enable automatic repository optimisation (enabled by default)

This future is there to optimise the local repository storage structure. Keeping things running efficiently and quickly.

Mendix MPR storage

The MPR file is the source of your application. All the Mendix logic, your domain model, and everything else are there.

Version 1

The original version we have used all these years has all of the Menidx special sauce stored in a single file. This file could grow depending on the size of your model. You will see your application and all its elements when you open it with Studio Pro or the MPR tool. All this time, it has been an SQL lite database with binary JSON. Do not try to edit it that way, though.

Version 2 BETA

As Git has issues handling all changes in one ever-growing MPR file, Mendix has introduced MPR version 2. This version uses the MPR file as an index that points to smaller files in the mprcontents folder. This should allow Git to handle the changes in your model correctly. As it currently is in a BETA, usage is at your own risk, and you should not try it out on applications that do not have room for experimentation.

You may migrate to MPR version 2 (or revert) in Mendix 10.18+ when you open up your application in Studio Pro, go to your File menu and click Upgrade app to split MPR format (v2)...

Git is the way forward!

Mendix is not going back to SVN, and they should not. Git is the way forward.

Have you adopted Git as yet??

Or are you stuck on an SVN repository that is too large to migrate and waited for the migration without a history feature?

#mendixignite #mendix #git #lowcode