Dev to UAT Merge Conflicts

0
Environment: Mendix 9.24.4, SVN-based Team ServerRecently observed in a long-running Mendix project, some documents (microflows, pages, etc.) were, at some point, added to environment projects by manually copying and pasting them instead of using proper version control (commit/pull/merge). These documents look identical in name and function across branches, but their version history doesn't match up.As a result, merging Dev into UAT now regularly causes conflicts. Sometimes the merge completes without any conflict shown, but the merged result is missing functionality or has overwritten logic — and this has occasionally reached Production before being caught.Questions:How can I identify documents with this kind of mismatched/duplicated version history before merging?What's the best way to reconcile such a document into a single clean lineage without losing logic from either side?Is there a recommended process to merge safely going forward and prevent silent loss of functionality?Any guidance or shared experience would be appreciated.
asked
2 answers
0

Hi Shadharan,


Are you running a permanently separate branch for each environment? If you are, then ideally you'd want to change this so that in the future you are running off the mainline, and branching for each new feature before merging back to the mainline when it is completed. You'd avoid having clashing branches merging between environments using this approach because any changes would be in the same feature branch.

https://docs.mendix.com/refguide9/version-control/#branches


However, to fix your current problem, you could merge the UAT branch back to the Dev branch. That should bring the changes made in UAT back in line with Dev, where it is probably safer to fix any conflicts. Once it's merged, it would be safe to merge to your UAT branch. When merging, make a note of which items have a conflict and then resolve using theirs, which should be the UAT branch. You can manually compare those conflicted items if you have an older copy of the original Dev branch in another instance of Studio Pro. This will let you see what the change in functionality is, and you can decide if you need to recreate it in Dev again or not.

I hope this helps, good luck!

answered
0

Hi Shadharan,

Since you're using SVN, I would recommend using TortoiseSVN to investigate the affected documents before trying to merge them again.


For a document that is causing conflicts:

  1. Take the corresponding Dev and UAT working copies.
  2. In TortoiseSVN, right-click the project folder and use Show log to check the history.
  3. Find the revisions where the affected microflow/page was originally added or modified.
  4. Compare the history of the same document in both branches. If the document was manually copied at some point, you may notice that the two branches have different revision histories even though the document looks identical.
  5. Use TortoiseSVN → Diff with previous version / Compare revisions to identify the actual logic differences.
  6. Once you understand the differences, consolidate the required logic into one document in Mendix Studio Pro.
  7. Commit that consolidated version properly to SVN and then perform the Dev → UAT merge again.


For future development, I would avoid manually copying Mendix documents between branches. Always use the SVN commit/update/merge workflow so that SVN can maintain the correct history and lineage.


Also, before merging into UAT/Production, I would recommend checking the TortoiseSVN log and revision graph for any documents that have been manually copied in the past. This can help identify potential problems before they result in silent functionality changes.


If a merge completes without an SVN conflict, it doesn't necessarily mean that the resulting Mendix logic is functionally correct, so the affected microflows/pages should still be reviewed and tested after the merge.


Kindly mark this as the accepted answer if it helps.

answered