Question

Project branch merge alternatives?

1

Dears, I am currently facing a challenge for which I like to ask your help. One of our projects has made a great number of changes in their branch and now its a huge effort if this is to be merged to Main Line. There are over 300 conflicts, on model items and also some on files. What may complicate matters is that the project branch was split from another branch and not direcly from Main line. Does anyone have experience with such a case and what is the way to solve it? I would like to know if there is another way that the merge to Main Line can be done as classic merge within Mendix doesnt seem possible: 1) Is there an option to accept all changes coming from the project branch? Maybe using TortoiseSVN? 2) Or can I copy all content of the project branch into the Main Line folder and then commit it? How risky is such an operation? Of course, I know I should start with a backup of the folder. Then I copy .mpr, folders javasource, resources, theme, userlib, widgets. Is this correct and complete?

asked 2016-11-24

David de Groot

3 answers

Kilian Croese · Answer 1 · 2016-11-25

Hi David,

First some questions:
- Have you merged from the main line or the parent branch lin to your project branch line? If that is the case, my experience is that merging complex changes doesn;t work well in Mendix.
- Do you have other branches that you would still like to maintain?

If i understand you correctly you basically want to replace what is currently on the main line with the contents of your (well tested and in production) project branch?

1) Is possible, more on that later
2) I would advise against just copying the contents, since you will loose the history and version control meta data.

In simple situations where you have not merged from the main to your branch lines i agree with Reinout. I would advise against just copying the mpr as Reinout basically points out.

So as promised, if you would like to "promote" your project branch line to become the main line i would use a reintegrate merge. I think the SVN documentation about Basic Merging is pretty clear about this, and it can easily be done with TortoiseSVN

Reinout van Schouwen · Answer 2 · 2016-11-24

Hi David,

The recommended approach in such cases is to first merge the changes on your feature branch (x') to the branch (x) you split off from. Once you have that, merge that branch (x) to mainline (use Advanced merge to hand pick the from-to revision range).

1) It is possible to accept all changes from the project branch (x') using TortoiseSVN, simply replacing the mpr and resolving other conflicts manually. I'd recommend resolving model conflicts within the Modeler though ("use theirs" in the Changes dock for each conflict) unless you're absolutely certain you can discard any change that may have been made on the main line after the branch (x) split off.

2) You can do that but there's a risk that you commit files (jars, custom widget mpks etc.) that have been renamed/deleted in one of the branches and are now superfluous. If you want to go this route, at least use the common sense approach of opening the resulting project in the Modeler and creating a deployment archive (mda) out of it and see if it builds correctly. If this is the case then you can safely proceed.

David de Groot · Answer 3 · 2016-11-25

Hi Reinout,

thank you for your kind and elaborate answer.

On approach (1) using the modeler only is not really feasible in this case. It will take days of right clicking on 'use theirs' to solve all conflicts. I know for sure I can accept all as the project branch was thoroughly tested and is now in production for several weeks.
So if I understand correcly, I can use the modeler to pull in the changes and then I can change the files in the project directory to get it done (kind of a mix of the both approaches now):
project.mpr           --> remove
project.mpr.bak    --> remove
project.mpr.merge-left.r###   --> remove
project.mpr.merge-right.r### --> rename to project.mpr

Of course, I would still have to solve the other file level conflicts. And then, run local and test. And finally make package to deploy on the test environment and test fully everything (Integration, End-to-end, etc.).

Do you have any comments on this?