Reading Information Messages After Resynchronizing
In addition to displaying any conflicts, the Resynchronize Document action displays the informational conflict icon 
in the headers of rows with information messages. These messages indicate structural differences that exist because content rows have been inserted, moved, or deleted in the document on the server.
in the headers of rows with information messages. These messages indicate structural differences that exist because content rows have been inserted, moved, or deleted in the document on the server.If you place the mouse cursor over an informational conflict icon, a tooltip indicates that the item has information for you to review. When you click an informational icon, the information message is shown in the editable item view. For example, the message can indicate that the item was moved from its original location as a result of changes on the server.
While you must resolve all edit conflicts and delete conflicts before you can successfully save your changes to the server, you do not have to act on informational conflicts. Their purpose is to notify you about structural differences caused by insertions, moves, or deletions on the server in case you want to make additional changes before proceeding to save your document. In general, the last change saved to the server is the winner.
Informational Conflicts Related to Inserts
Assume that X is inserted in the document. For any of the following conditions, an informational conflict icon appears on the inserted item:
• The parent under which X was inserted has been moved or deleted on the server.
◦ If the parent of X was moved, these checks are performed to determine whether to show an informational conflict:
▪ Is the parent the same?
▪ Is the previous sibling the same? The previous sibling is the item that is above X and at the same level as X.
▪ Is the path to the document root the same?
▪ If the previous sibling is an inserted node, is the first real previous sibling the same?
Assume that you have the following document structure:
A
--B
---C
--D
--B
---C
--D
where B and D are children of A, and C is a child of B.
On the client, you insert X as the second child of B. On the server, B is moved as a section (so C is included) below D.
Resynchronizing places B below D. The new node, X, is still a child of B. At this stage, all of the checks pass:
▪ X’s parent is still B.
▪ X’s previous sibling is still C.
▪ X’s path to the document root is still “X, B, A, document root”.
▪ X’s previous sibling is not an inserted node.
This means that no informational conflict is shown.
However, assume that B was moved on the server such that it was no longer a child of A, such as outdenting B. After resynchronizing, the path of X to the document root changes. It is “X, B, document root”. This causes an informational conflict to be shown.
◦ If the parent of X was deleted, X is automatically reparented under the first ascendant that was not deleted.
• The sibling after which X was inserted has been moved or deleted on the server.
◦ If the sibling of X was moved, X is still inserted below the same sibling, wherever the sibling has moved. This assumes that the sibling has moved within the same parent. If the parent of the sibling has changed, then X is still inserted as a child of its existing parent, but it takes the sibling’s place. For example, if the sibling was the second child, X becomes the second child. The parent takes priority over the sibling when considering the new insert location.
◦ If the sibling of X was deleted, then the siblings above X are examined in reverse order to determines where X is inserted.
• The path from the root document to X has changed on the server.
◦ This is the case when either the parent of X has moved or a parent in X's hierarchy has moved so that they had different parents themselves.
In all cases, X is now in a different location on the server from where you originally put it. The informational conflict on X notifies you of this difference. In all cases, field modifications to the parent of X, the sibling of X or any ascendants or descendants of X are ignored in respect to determining conflicts. However, all of these modifications appear in the resynchronized document.
Informational Conflicts Related to Moves
Assume that X was moved from one position to another. Here are the ways in which different move scenarios are handled:
• X was deleted on the server.
◦ X is removed from the view, and a resynchronize error occurs. For more information, see “ Resynchronize Errors” in Troubleshooting During Multiple-Row Editing.
• The parent of X, as visualized on the client, was deleted on the server.
◦ X is automatically reparented under its first ascendant that was not deleted.
◦ An informational conflict is displayed on X. The information message indicates that the position of X has changed from what you originally determined.
◦ No options are present.
• X moved to the same location on the server.
◦ No conflict or informational conflict is shown. For this case, X is in the same location on both the client and server and so is ignored.
• X moved to a different location on the server.
◦ The client move is respected.
◦ No conflict or informational conflict is shown.
• X’s structure has changed on the server due to the insert, delete, or move of content items.
◦ This scenario is ignored except in the following situations, when an informational conflict is shown:
▪ X’s previous sibling was deleted on the server.
▪ X’s previous sibling was moved such that it no longer has the same parent. Because the parent has higher precedence over the sibling, X remains with the parent.
In all cases, field modifications to the parent of X, the sibling of X, or any ascendants or descendants of X are ignored in respect to determining conflicts. However, all of these modifications appear in the resynchronized document.