When you merge application changes by running the Merge-NAVApplicationObject cmdlet or the Update-NAVApplicationObject cmdlet, the differences are applied automatically if it is possible. However, when conflicts are detected, they are captured in CONFLICT files. The CONFLICT files clearly identify where two parties such as you and Microsoft have changed the same object or parts of it.You can open a CONFLICT file in Notepad, for example, and see the type of conflict, such as a code conflict or conflicting object property values. By clearly identifying the conflicts in this manner and automatically merging all other changes, you can more easily resolve the conflicts.

Identifying Conflicts

Depending on your application, the merge process often identifies one or more conflicts. The CONFLICT files describe differences that were not automatically merged. This includes conflicting code modifications, property settings, and application code. Each conflict is clearly marked in the corresponding application object text file in the RESULT folder. A copy of the files in ORIGINAL, MODIFIED, or TARGET that caused the conflict is added to subfolders to the RESULT folder.For example, if you run the Merge-NAVApplicationObject cmdlet on three different versions of codeunit 1, and a conflict is found, the RESULT folder will contain the following:

Folder File name Description

RESULT

COD1.CONFLICT

Describes the conflict, such as a code modification in a function.

COD1.TXT

The merged application object that has the conflicting code clearly marked.

ConflictModified

COD1.TXT

The conflicting application object from the MODIFIED version.

ConflictOriginal

COD1.TXT

The conflicting application object from the ORIGINAL version.

ConflictTarget

COD1.TXT

The conflicting application object from the TARGET version.

Since the CONFLICT files describe the conflicts, you can import the merged text files into the Microsoft Dynamics NAV Development Environment and resolve the conflicts there. Alternatively, you can use an external three-way merge tool to analyze the conflicts.

In most cases, the text files that contain the merged application objects clearly identify where the conflict is. The following code example illustrates an object that has a conflict.

 Copy Code
    PROCEDURE ApplicationBuild@3() : Text[80];
    BEGIN
      {>>>>>>>} ORIGINAL
      EXIT('35473-ORIGINAL');
      {=======} MODIFIED
      EXIT('35978');
      {=======} TARGET
      EXIT('35473');
      {<<<<<<<}
    END;

In this example, the ApplicationBuild function is different in all three versions of codeunit 1 that you tried to merge. If you import this file into the development environment, it will not compile. You can resolve the conflict in Notepad, a three-way merge tool, or in the development environment. Use the source files in the subfolders in the RESULT folder to learn how to resolve the conflict.

See Also