How does Mendix Studios consistency checker internally prioritize and resolve conflicting model changes during collaborative multi-user development?

0
Hi to whom it may concern,I am wondering when two or more developers are working simultaneously on the same Mendix app in Studio Pro with Team Server enabled, and they both make changes to the same microflow or domain model at the same time, I understand that Mendix uses a version control system to manage conflicts.However, my question goes deeper than basic merge conflicts:At what granularity does Mendix track model changes internally — is it at the element level, the document level, or something else?When the consistency checker flags an error introduced by a merge, does it use a deterministic resolution algorithm, or is it context-dependent?Are there any known edge cases where the merger silently produces a logically inconsistent model without raising a consistency error?I'm trying to understand the internals well enough to design a conflict-resistant team workflow for a large app with 10+ developers.Any insights from Mendix engineers or experienced team leads would be appreciated.
asked
1 answers
0

Hi Kwok, That's an excellent question. Conflict management can quickly turn into a nightmare. The simplest example is a massive update of translations into multiple languages ​​for an application developed by several developers... Conflict detection and resolution are very granular because all the information that defines a logic—whether business logic, code representation, or construction logic (organization of activities in microflows, positioning of actions, etc.)—is stored in the project's SQLite structure.


Now, regarding source control, what's recommended will depend on the scope of the project you're working on. If you have a large team, I would recommend having a clean main branch. This is the absolute standard. From there, for each deliverable (sprint if you're using an agile methodology), you can create a development branch that will be merged into the main branch at the end of the delivery. During the sprint, one branch should be created per feature (we'll assume that a feature is handled by a single person). The feature will be merged into the development branch when it's finalized. There's nothing stopping the developer from regularly updating their feature branch from the development branch. The idea is to properly isolate changes and maintain not only a clean main branch, but also a healthy development branch from which tests can be run by the testing team.

It would be interesting to share the types of problems you encounter and what solutions are implemented.

I hope this can help you a little in your thinking.

Patrick


answered