Caution! The merge cmdlets might merge incorrectly!

NAV2015 introduced new object merge functionality to ease upgrading of NAV databases dramatically. For information about the cmdlets you could start here: http://blogs.msdn.com/b/nav/archive/2014/10/03/merging-application-objects-using-windows-powershell-in-microsoft-dynamics-nav-2015.aspx

I reported an issue to Microsoft back in the middle of December 2014, and after more than one month of e-mails back and forth I got this response:

(…)
This by design and won’t be fixed. We are applying a 3-way merge on the function body including comments. The 3 merge searches for similar code when doing a merge an the out-commented code gives the best match. The customer would see a similar issue by using other 3-way merge tools like Beyond Compare. The current design also supports merging of comments which can contain valuable information that should also be merge.
(…)

I now give up, and instead of trying to convince Microsoft to fix the cmdlets, I instead wish to warn the NAV community about this issue. The main issue is, that the tool claim to show which objects with conflicts the NAV developer needs to handle manually and which objects was merged automatically without conflicts. However; in my example below, it claims there are no conflicts, but the merge is incorrect. 😦

My first error report was rejected with the argument my C/AL code did not comply with the guidelines specified here: https://msdn.microsoft.com/en-us/library/ee414237.aspx That meant Microsoft initially said the merge cmdlets might fail if your code was indented incorrect or your variables were not in the right order 🙂

Enough teasing, here is the problem: If either the Modified or Target object set uses braces (”{” and ”}”) to disable code, then it might merge incorrectly and claim everything is ok. The usage of braces is not recommended by Microsoft, but it is not until NAV2015 we have been able to easy block comment code with “//”. Using braces has always been possible and even described here: https://msdn.microsoft.com/en-us/library/dd301180(v=nav.70).aspx

Many NAV customers have had several VARs modifying their objects and their current VAR might not know if braces are used or not. My current company has a company policy to use braces when code is changed. There are pros and cons with this approach, but the point is, that there is no (easy) way to check if anyone ever used this approach in a NAV database.

Here is an example with a dummy modification in a simple codeunit using braces: (left=base, right=modified)

Let us imagine Microsoft also made a change in the codeunit: (left=base, right=target)

Here is the result from the merge cmdlets: (left=base, right=result)

As you can see, the cmdlets simply merges Microsoft’s code changes into the comment section of the Modified object. I do not claim the cmdlets should necessarily merge the code into the code section, but it should at least consider this to be conflict. As it is right now, then no developer would notice this potentially critical problem.

What do you think – is this just a theoretical problem, or does this make you more careful using the merge cmdlets?