Hi Hessel,
I have seen something similar before as well. If you open the .project file in an editor there is a <name>-tag which reflects your folder name(?).
If you have main line or any other branch in different folders I think that it will create the modification.
If you have turtoise svn installed you can look at the difference between the base and your changed file to see what differs.
/Johan
I have also seen this happen. It can easily be reproduced using the following steps (although this might not be the cause of the behavior in this specific case)
1) Open a project with no changes (fresh from teamserver, or right after a successful commit)
2) Make a change in the modeler (e.g. move a microflow step or add a widget to a page) and perform a save
3) Revert the change you just made
I suspect that it has to do with the fact that the last changed date of the project file is updated, which register as a change for svn although nothing has actually changed..
The way the model is stored means that after certain operations the bytes of the mpr file can be different although they represent the same thing. This is nothing to worry about but we need to show a change because SVN sees a different file.
Hi all,
I would like to add to this discussion that this issue does prevent you from pulling from the Team server.
You have to commit this non-change before pulling. So it is harmless but a bit annoying...
Hi,
This message is expected behavior and is related to how Mendix Studio Pro stores project metadata internally. It does not necessarily indicate actual model changes.
Let me clarify what is happening.
Mendix projects are not stored as a single file. Instead, they consist of:
The message:
“The project file is modified even though there are no model changes. This can happen because of the file format used for modeler projects.”
means that non-functional metadata inside the project file has changed, even though no domain model, microflow, or page logic has changed.
This typically happens because:
These are structural or formatting-level changes, not logical model changes.
In version control, these differences often:
That is why you cannot identify visible changes in Studio Pro.
Indirectly, yes — but not in a problematic way.
Possible triggers:
Studio Pro sometimes rewrites project files to align with the current internal format.
In most cases:
It is generally safe to commit these changes.
You should investigate further only if:
Otherwise, this message is informational and not an error.
This message indicates internal project file metadata changes, not actual model changes. It is normal behavior related to the file format and Studio Pro’s internal structure management.
It is safe to commit these changes if no functional modifications were made.
This explanation aligns with Mendix project structure behavior and common version control experiences in team environments.