This topic gives a detailed explanation about some of the difference types you will encounter in a View Compare/Merge session.
Below are some of the difference types you may encounter during View Compare/Merge sessions and their corresponding row numbers. This section discusses what to do when the difference type results in the default merge action Fail. Unless another merge action is selected for items that Fail, the View Compare/Merge session cannot be committed. Often you want to make some data repairs in these cases and then redo the View Compare/Merge session. Sometimes you will simply ignore the situation temporarily so that you can commit other files. Later, you can perform a repair.
Defaults to Fail.
This difference type is applied dynamically. Whenever an item resides in a folder to which a View Compare/Merge session has already assigned the merge action Fail, then that item also fails, but with difference type Parent Folder Failed (Row 100). If you change the parent folder’s merge action, the merge action for the items within that folder will also change.
For example, suppose an item A has the difference type Parent Folder Failed (Row 100) because its parent folder B had difference type Target folder has floating child share in source view (Row 200). If you change B's merge action from the default Fail to Ignore, the parent folder no longer fails. Item A’s difference type also changes to Parent Folder Ignored (Row 110). If you want to commit changes to item A, you must fix folder B so that it is not floating in the target view, refresh the view, and redo the View Compare/Merge session.
Defaults to Ignore which is also the only available action.
This difference type is applied dynamically. Whenever an item resides in a folder to which a View Compare/Merge session has already assigned the merge action Ignore, then that item also ignored, but with difference type Parent Folder Ignored (Row 110). This allows you to commit the other resolved items.
However, you can correct the parent folder and also commit the items with this difference type. For example, suppose an item A has the difference type Parent Folder Ignored (Row 110) because its parent folder B had difference type Deleted in target (Promote) (Row 620) or Deleted in target (Row 600). If the deleted folder belongs back in the target view, you would change B's merge action from the default Ignore to Share or Reverse Share. Because the parent folder issue has been resolved, item A’s difference type changes from Parent Folder Ignored (Row 110) to a more appropriate difference type. For example, this item may also be Deleted in target (Row 600) or it may be New in Source (Row 500) In either of these cases, you may now change item A’s merge action to Share or Reverse Share.
Unlike the Fail difference type, Parent Folder Ignored (Row 110) usually does not require you to make changes to the repository. Instead, this is used in cases where Ignore is the only thing that makes sense, based on a decision you have already made about the parent folder. For example, suppose you have a file that is New in source (Row 500), but the parent folder was Deleted in target (Row 600). The default action for the folder is Ignore, which implies that there is no parent folder in the target into which the new file can be shared. That is why the file gets the Parent Folder Ignored (Row 110) difference type. If you override the action on the folder to Share, the file becomes New in source - Share. The Parent Folder Ignored (Row 110) difference type no longer applies.
This section discusses Floating Share difference types: Floating Child Share (Rows 1210), Floating Child Share(Promote) (Rows 1220, and Floating Child Share, Source Unbranched (Promote) (Rows 1230). These types occur only when you use the Fix floating child shares option in the View Compare/Merge Wizard.
The intent of the Fix floating child shares option in the View Compare/Merge Wizard is to locate items in the target view that:
The operation type affects which difference type is selected by View Compare/Merge. If you are not doing a promote operation, the difference type is Floating Child Share (Row 1210). If you are doing a promote operation, the difference type is Floating Child Share, Source Unbranched (Promote) (Rows 1230). On earlier releases of StarTeam Server, you will see Floating Child Share (Promote) (Row 1220) because earlier releases were not able to reverse share items in as many circumstances.
A floating child item can cause problems. For example, adding an item to a floating child folder in the target can result in that item floating back to the source as a duplicate. Adding a new revision to an item that is floating in the target can result in that revision inadvertently floating back to the source. If the entire view is branch-all floating or branch-none floating, this can happen frequently. That is why StarTeam, depending on how your administrator has set up the StarTeam Server, now either:
Defaults to Repin. Optionally, you can select Ignore.
The best and most common practice in StarTeam is for parent > child relationships in the share tree to match the parent > child relationships in the view hierarchy.
This difference type occurs only when you check the Fix floating child shares option in the View Compare/Merge Wizard. You use this option to stop the creation of unwanted duplicates in the source as an item floats from the target back into the source.
The intent of the Fix floating child shares option in the View Compare/Merge wizard is to locate items in the target view that have their parent reference in the source view, and are also floating. Because of this, the rebase operation finds items in the child view that correspond to items in the parent view, and pins them if they are floating. The difference type is Floating Child Share (Row 1210). If you allow View Compare/Merge to re-pin in this case, it changes the floating items to the configuration time of this particular View Compare/Merge session when the session is committed. This is a good idea because you will not have problems with these items in the future.
If you are performing a replicate operation, the references in the reference tree and the views in the view tree may not be pointing in the same direction (from parent to child), but the results will be the same. View Compare/Merge offers to repin these items in spite of their reference relationship because the two views in the View Compare/Merge session are probably not parent and child anyway.
For example, suppose a folder was shared from the parent view to each of two child views, set to branch on change in each child view, but allowed to float in the child views. Because View Compare/Merge alerted you, you changed the folder in the first child view so that it is now pinned. Nevertheless, if you promote an item from that folder in the now corrected child view to the parent view, the item will float down to the other child view from the parent view if no intervention has taken place in that view.
If the creation of floating views was common practice, it is best to pin items in all the project’s child views before a View Compare/Merge commit operation. It is also a good practice to pin floating items after they are shared to a new location.
Defaults to Delete-and-Reverse-Share. Other merge actions available are Ignore and Repin.
This difference type occurs only in promote operations when you check the Fix floating child shares option in the View Compare/Merge wizard. You use this option to stop the creation of unwanted duplicates in the source as an item floats from the target back into the source.
This difference type allows View Compare/Merge to do more than Fail when a floating share is found during a promote operation. If you perform a Delete-and-Reverse Share, the reference tree is corrected. Since both items are on the same branch, re-pinning is also a viable option because it does not cause an unwanted duplicate item to occur.
Defaults to Fail. Optionally, you can select Ignore.
This difference type occurs when the item being processed by View Compare/Merge exists only in the source folder. Without the folder problem, this item might have resolved to one of several different difference types:
This situation produces a Fail condition because if the item were moved, shared, or reverse-shared in the target, a duplicate copy of the item would float back into the source folder. You may see Share, or another of the possible merge actions, in the Default Action column for this item. This is because without the floating folder problem, the item’s default merge action would have been Share. Because of the floating folder problem, View Compare/Merge overlays the item’s difference type with the Target Folder Has Floating Share In Source View (Row 200) difference type. View Compare/Merge elects to Fail rather than cause multiple copies of the item in the source folder.
For example, suppose a folder was shared from the parent view to the child view, set to Branch on Change in the child view, but allowed to float in the child view. Further suppose that a new file was added to the folder in the child and you are promoting that item to the parent view. Normally, this file’s difference type would have been New in Source and View Compare/Merge’s default action would be a Reverse Share. However, in this case, performing that action would cause a duplicate copy of the item in the source folder. That is why View Compare/Merge uses Target Folder Has Floating Share In Source View (Row 200) in this case instead of New In Source (Promote) (Row 510).
You can ignore this situation by changing the action for the item to Ignore and then commit the rest of the session. Or you can end the session, go to the folder in the source view, and manually change its configuration from floating to pinned. When you redo the View Compare/Merge session, the item that had the difference type Target Folder Has Floating Share in Source View (Row 200) will have a different difference type, such as New In Source. The item’s default action will be one of the merge actions listed earlier, and there will be no Fail condition.
It might be wise to check the other references for this folder to see if they, too, are floating—even if they are in other views—just to be sure that items will not float into other views that are not involved in this operation.
This series of difference types all have similar names but very different consequences.
Defaults to Share. Optionally, you can select Ignore.
This item exists in the source but has no match in the target view. If this is a Rebase operation, the operation is going in the same direction as the view tree: from parent to child. In a Replicate operation, that may not be the case. Nevertheless, in either operation, View Compare/Merge shares this item into the target view at its current location in the source and pins its configuration to the time of the View Compare/Merge session.
Defaults to Reverse Share. Optionally, you can select Ignore or Share.
This difference type only occurs in promote operations. The only difference between New In Source (Row 500) and New In Source (Promote) (row 510) is that the View Compare/Merge operation is going in the opposite direction as the view tree: from the child to the parent.
To be sure that the reference tree for the item goes in the same direction as the view tree, View Compare/Merge does a reverse share. Next, the item’s configuration is pinned to the time of the View Compare/Merge operation.
When View Compare/Merge reports a status Unchanged, it does not necessarily mean that the items have not been changed since the last View Compare/Merge session.
For example, suppose you change an item in one location and the changes float to another location. If these two items are compared in a View Compare/Merge session, View Compare/Merge reports Unchanged because the two items are identical.
For example, suppose changes have floated to both the items being compared. and then the child item changes again and branches, View Compare/Merge perceives that the pair was the same and that then the child changed. It does not recognize that both have changed since the original share or last View Compare/Merge session.
The floating issue can affect many rows of the View Compare/Merge Action Decision table.
If the files in one view and the files in another view have a common ancestor but are in different locations, they are reported as moved by View Compare/Merge because a move appears to have taken place. However, that may not be the case. They may have been shared manually from one view to a different location in another view initially. No move has really occurred. What View Compare/Merge is actually reporting is that they have different locations.
Suppose that all files were shared to a folder other than the corresponding folder in the other view, and were then moved to the corresponding folder.
For example, in Moved In Source (Row 1900) promote: