How View Compare/Merge Handles Target Folders with Floating Shares

View Compare/Merge, by its very nature, tends to perform many move, share, and reverse-share operations. If one or more of the target folders has floating child shares elsewhere in the repository, and if View Compare/Merge performs a share, reverse-share, or move operation, View Compare/Merge could appear to be creating extra copies of items during the commit. Items could be automatically propagated to other locations throughout the repository, often creating floating child shares unintentionally. In such cases, subsequent operations that trigger automatic propagation can cause unexpected results.

To prevent this from happening, View Compare/Merge is defensive in the presence of folders that have floating child shares. It recognizes situations where an item is being shared, reverse-shared, or moved into a target folder that has active floating child shares, and disallows the operation reporting a Fail. To resolve the situation, you can review each failed difference and change the action (for example, to Ignore) before committing the session, or correct the floating share problem and redo the session.

Note: When matching an item for which there are multiple shares, View Compare/Merge prefers matches whose parent/child share relationship is the same as the parent/child relationship between the source and target views.

Example Move Operation in View Compare/Merge

Move operations present an interesting problem for View Compare/Merge. Consider the example below.

In this example, an item has been moved and modified in a child view. View Compare/Merge is then used to promote the changes to the parent view.

Suppose the user were to select Move and Merge as the current action for File.doc. In this case, the selected action would move the item into Folder B, which has floating child shares elsewhere in the repository. View Compare/Merge must therefore prevent the move operation from occurring.

On the other hand, if the user were to set the action to Merge, then the item would remain in its existing folder, and the operation would be permitted. Thus, View Compare/Merge must recognize the possibility that certain operations may change the target folder, and enable and disable actions appropriately as the target folder changes.

Target Folder Has Floating Shares

The View Compare/Merge engine has a difference type called “Target folder has floating shares” which is unlike the other difference types in that it is never selected from the View Compare/Merge Action Decision Table based on the MatchState that describes the relationship between a source item and target item. Instead, it is overlaid on top of an existing DifferenceType in the context of a given DifferenceType, based on an analysis of the target folder that would result from the currently selected action.

Consider again the example above. Use the View Compare/Merge Action Decision Table rows as the reference, where row [2] is “Target folder has floating shares”, and row [30] is “Moved and modified in source, target on different branch”. In this case, the difference type selected from the decision table for File.doc is:

Row [30]: Moved and modified in source, target on different branch
    Action: Merge
    Legal Actions: Merge; Ignore; Move; Mark Resolved; Move and Merge; Overwrite

When a client application requests the difference type for this ItemDifference, the View Compare/Merge engine looks at the currently selected action, and determines whether or not a move, share or reverse share will be performed. At this point, the current action is Merge, and therefore nothing special happens.

Now, suppose the user sets the action to Move and Merge. In this case, when the client application requests the difference type for this ItemDifference, the View Compare/Merge engine notes the move operation and determines whether or not the new target folder has any floating child shares. If it does, then the engine does not return the actual difference type, but instead returns “Target folder has floating shares”.

Furthermore, the View Compare/Merge engine presents a different current action, and a different set of legal actions. These are determined dynamically, by removing all of the problematic actions and replacing them with Fail. Thus, by overlaying row [2] over row [30], the engine exposes the difference type to client applications as if it were the following:

Row [2]: Target folder has floating child shares

    Action: Fail
    Legal Actions: Fail; Merge; Ignore; Mark Resolved; Overwrite

Suppose now that the user changes the current action back to Merge. At this point, the engine no longer needs to overlay row [2] over row [30]; it exposes the difference type, current action and set of legal actions in their original, unaltered forms.

Frequency of Checking for Floating Shares

You should note that there is no way to prevent you from adding new floating shares. Thus, no matter when View Compare/Merge checks, it is always possible that a new floating share is added immediately afterwards, and is missed.

Checking often for a floating child share would decrease the likelihood that we would miss one. However, since this test is lengthy and resource intensive, this would result in unacceptable performance.

Currently, View Compare/Merge only checks for floating child shares in the source view since the source view is already open, and since checking the source view can be done rather easily and quickly.

To improve performance, View Compare/Merge checks each target folder at most once per session. However, for sessions that are saved and then later restored, View Compare/Merge checks again when the session is restored.