Hi! PM for Version Control here.
We are aware of the issues with some 3rd party Git hosts due to file size limitations, such as Github. With the .mpr file growing over time, it’s not possible at this point in time for customers with large .mpr’s to use those services.
As mentioned by Support, Git LFS is not a real solution to this problem, as LFS is designed for files that don’t change often.
This leaves us with the direction of moving to a different format for Mendix projects. We are investigating what benefits this would bring (enabling Github, possible effects on performance while working with Mendix, ...) and what impact this would have (as lots of parties down the line use the current .mpr format).
At this time I can’t provide clarity yet where we are heading, but I will emphasize this problem is known to us, and we’re investigating how to address it.
Thank you for your clear answer.
I agree GIT LFS is not a real solution, it’s only a workaround waiting for the real fix : breaking this MPR.
On my optinion, Mendix cannot say it supports git server providers (Working with Git On-Premises Version Control Server | Mendix Documentation) until it fixes that issue with MPR file because no large project would be able to be versionned on gitlab nor github (max 100MB file size on each)
There seems to be a misalignment somewhere in Mendix: On one hand you will only support git as your VCS on version 10 (Mendix 10 Commits to Git | Mendix), on the other hand, only project with <100MB mpr file would be able to be versionned on github and gitlab, so exit large projects support.
It has been more than a year since this issue was first reported: https://forum.mendix.com/link/space/studio-pro/questions/114034 .
On my opinion, this lack of reactivity is concerning (if not frightening) and shows this issue is not a priority at all on Mendix side.
I hope Mendix will change its priorities soon.
Thank you for the response. Of the 4 largest Git vendors (Github, Gitlab, Azure, Bitbucket) we only found Github having a filesize limit, which is something we should address in the documentation you're referring to.
We are aware this is frustrating a part of our customer base, and it's clear this needs to be resolved.
Having said that, we are investigating the costs and benefits of splitting the .mpr, and are prioritizing it amongst other version control/Git frustrations.
Thank you for your reply.
For reference, I’m including mendix support answer on a ticket I created that complete your answer above:
I have checked your questions and concern with the SDM and PM of the relevant team. It is mentioned that as of now, the only service we are aware of that has a hard limit on file size, which cannot be resolved, is GitHub. We acknowledge the problem caused by this limitation on GitHub.
The size of the .mpr file increases as your app grows. One way or another we need to store the model and the metadata associated with that. We have made certain tradeoffs in this regard and are currently exploring whether we need to change our approach by leveraging Git and incorporating planned future features. It is worth noting that the .mpr file format offers several benefits such as consistency and faster reading and writing speeds, which are challenging to replicate with separate files. Nonetheless, we recognize the importance of having a sustainable and performant file format for our metamodel.
However, changing the .mpr file format is rather complex. We understand the inconveniences caused by the large .mpr file size and are actively investigating alternatives to move away from a single big binary format (.mpr) to another format. Please note that this investigation is still in its early phase, and even after a decision is made, it will require several quarters of time for implementation.
With that being said, we do not consider the size of the .mpr file as a bug. Upgrading Studio Pro will clean up the file, but the overall gains from this process are typically limited and may not sufficiently resolve the issue. While improving the user experience remains a priority, it is not guaranteed yet that we will change the .mpr file format. An example of our commitment to enhancing the user experience is the introduction of automated Git garbage collection, which effectively resolves repository size issues.
Until it is resolved, it is not possible to use GitHub with projects that have a large .mpr file. We apologize for any inconvenience caused and appreciate your patience as we work towards finding a solution.
We have the same issue about MPR size.
The MPR size is already over 100MB capacity, and the github policy does not allow this.
Did you receive any solutions from the Mendix team to solve this problem?
If not, I would appreciate it if you could share how you are solving the MPR size issue in other ways.