New in Mendix 3.0: Version Control

Version control is one of the more exciting features available in version 3.0 of the Mendix Agile Business Platform. Every business engineer I’ve talked to is revved up about how easy and automated this feature makes application development for distributed project teams.

If you’ve ever been forced to use an external change management system to handle your versioning needs, you’ll understand the implications of having this functionality nestled into your design and runtime environments.

Check out the documentation for the whole story, but here’s the scoop:

Version Control: History

In version 3.0 you have a centralized repository that contains both your model and resources. Each person working on the project has a local copy – this has a few benefits, most notably, its scalability. Because people work independently on local copies and not on one model, more people can work on the same project without constantly interfering with each other. Working offline is another welcome benefit, along with the speed at which you can develop without being constrained by the speed of your broadband connection.

We chose Subversion because of its popularity, maturity and solid Windows support. Building on top of Subversion means that we inherit its reliable protocols for sending and receiving changes. Subversion has a lot of operations that allow us to support advanced features like branching and merging. The Modeler simplifies Subversion commands by providing a layer over them. All common operations can be executed right from the Modeler.

Version control changes the way you collaborate on a project. Instead of having one model where everyone directly saves all their changes, you work on your own copy of the project and choose an appropriate moment for uploading your changes to the repository and downloading changes from others.

Uploading your changes is called ‘committing’ (for most developers this is common lingo, but as you can build apps as a business engineer as well we’d like to be accurate). A commit is accompanied by a user-supplied message describing the changes so that you can quickly see what has happened when reviewing commits. Retrieving changes by others is called ‘updating’ and, like commit, is an explicit action. It can be compared to ‘refresh’ in the old way of working. However, it does not happen automatically when you open a project.

Since each revision is stored on the Team Server, you always have not one but dozens of backups of your project. You can always revert changes that you do not like or look at the project as it was a week ago. Together with the reliability and consistency improvements, you can develop with more confidence and we think that this is the best thing about version control.


Share to Social Media