If a new revision of an item is created in a shared location while the Branch On Change property is on for the item, a new branch is created for that item and is reflected in the dot notation for the tip revision. Once the item has branched, it will not branch again unless it is shared again.

In the location where an item was first created, it cannot branch. When an item is shared, it can acquire branching behavior. By default, the shared item acquires the branching behavior set by the Branch On Change property for the view, but this property can be reset manually for each item. If the behavior is set to Branch On Change , the next revision will branch, adding a new pair of integers to its dot notation.

If you compare the dot notation for two revisions, you can determine if they are on the same branch or on different branches. If the two dot notations have the same number of integers and those integers are identical (except for the last integer), then the revisions are on the same branch. A difference in the number of integers, or a difference in the value of any integer except the last, indicates that two matching items are on different branches. For example, 1.7 and 1.7.1.0 are not on the same branch. 1.7.1.0 and 1.7.2.0 are not on the same branch. 1.7 and 1.9 are on the same branch. 1.7.1.8 and 1.7.1.15 are on the same branch.

The common ancestor of two matching items is the most recent revision of the item to appear in the histories of both items, or if merge points are being used, the source revision for which the merge point has been set. For example, suppose that the root view is the source view, one of the branching child views of the root is the target view, and merge points have not been set. If the item in the source has the dot notation 1.9 and the item in the target is 1.7.1.2, the common ancestor is 1.7 and probably was the tip revision at the time that the child view was created. View Compare/Merge uses the common ancestor of the matching items to determine if changes have been made to the source and target items.

The properties or contents of two matching items require manual intervention in a merge situation. For file contents, conflicts arise if two matching blocks or lines of code have both been changed since the common ancestor or the most recent merge point. For properties, if a property has changed in both matching items, that property produces a conflict that must be resolved manually. If the property value of only one of the items has changed, that property does not have a conflict. If only the source property has changed, the difference for that property can be automatically resolved by overwriting the property value in the target with the property value in the source. If only the target property has changed, the difference is ignored.

Used to describe an item that is not identical in both the source view and the target view. For example, the item could be present in one view and not the other; it could be in both views but in different folders; it could be in both views but have different revisions, and so on.

A set of pairs of integers separated by periods indicating the branch that each revision is on and its place on that branch.

For example, suppose you add a file to a root view. The first revision of that file has the dot notation 1.0; the second revision has the dot notation 1.1, and so on. Suppose you create two branching views as children of the root view, and both child views include the file info.htm, and the tip revision of info.htm is 1.7 at the time the child views were created. Both child views will show revisions 1.0 through 1.7 in the history for info.htm. The history also indicates that those revisions were created in the parent view. Now suppose that someone changes info.htm in the first child view and checks in the file. The new revision (the first revision of info.htm in that particular child view) will have the dot notation 1.7.1.0. This is a new branch. To continue with the same example as before, suppose that a developer makes a different set of changes to info.htm in the second child view. As those changes are checked in, the dot notation of the new revision (the first revision of info.htm in the second child view for this file) becomes 1.7.2.0 and starts a new branch. The dot notation cannot become 1.7.1.0 because that branch has already been created in the first child view.

Shared items not configured to a specific label, promotion state, or timestamp are said to be floating. For example, suppose an item with the revision 1.7 was shared into a second view and allowed to float. As the original item moves to revisions 1.8 and 1.9, so does the shared item. When pinned, a share stops floating and stays at the revision number it is pinned to, unless it branches.

View Compare/Merge takes no action. It is always available as the action to be performed on any pair of matching items. It is sometimes the default action and sometime the only action available. For example, if an item has been deleted from the source, but its matching item is not only in use but has changed in the target since the last merge, View Compare/Merge expects that you will want to keep this item in the target view. The default action in this case is to ignore the differences between the two matching items.

When this action is selected, View Compare/Merge merges the properties of the matching items and creates a new revision in the target view. The merge can be done automatically or manually. If there are conflicts, the merge must be manual. View Compare/Merge also sets a merge point for future reference.

A merge point indicates that a merge occurred between a particular revision of an item in the source view and a particular revision of its matching item in the target view. Merge points are directional in that they denote which item was the source and which was the target. It takes precedence over the use of the common ancestor. In future comparisons and merges, if neither the source nor target item has changed since the merge point was set, View Compare/Merge takes no action. A merge point is set for any Merge, Overwrite, or Mark As Resolved action.

The overall view compare/merge strategy. The possible merge types are Rebase, Promote, and Replicate.

A Promote updates a parent view to reflect the changes made in one of its children. Changes in the child view usually result in branching, so changes are usually merged into the parent view. If the item exists only in the child, it can be reverse-shared into the parent. A reverse-share is a good idea because the parent view is the best location for an item that is the root of a reference tree.

A Rebase operation updates a child view to reflect changes made in its parent view. Items that have not changed in the child are rebased simply by re-pinning the item in the child view to match the current revision of the matching item in the parent.

Example of a Rebase: Suppose you create a child view based on the root view one week and wish you had waited. Several changes have gone into the root view in the past week, but little or no work has occurred in the child. A Rebase operation changes the child view so that each item is re-pinned to the current revision in the parent. If an item is new in the parent, it is shared into the child. If an item has branched in the child, re-pinning is not possible and a merge is necessary.

A branch-all variant (derived) child view whose purpose is to support continuing maintenance activities for a specific product release. A release view is created from the main view as of a specific milestone such as a view label. Changes to the release view support bug fixes or minor enhancements. Some of these changes must be replicated back to the main view or other release views. Some changes made to the main view must be replicated to one or more release views.

An item in a target view can be re-pinned if the two matching items are on the same branch. The act of re-pinning changes the common ancestor for a pair of matching items. It also moves the tip revision in the target view forward at least one revision. For example, if the item in the source view is 1.9 and the item in the target view is 1.7, re-pinning changes the tip revision in the target view to the 1.9 revision. It is equivalent to setting the configuration time of the item forward to a time after the creation of the 1.9 revision in the source view. The common ancestor for the two items is now revision 1.9. Re-pinning is most commonly done in a Rebase operation when the source view is the parent of the child view.

For views that are not parent/child, View Compare/Merge expects you to perform a Replicate operation. The actions available during a Replicate operation and the default action select by View Compare/Merge are the same as for a Rebase operation. However, while re-pinning may be the most used action in a Rebase operation, it may be the least used action in a Replicate operation. This is because, depending on the relationship between the views, fewer of the items will be on the same branch.

When an item is reverse-shared, it is moved from the source view to the target view and then shared back into the source. The items in both views have the same data, the same number of revisions, the same dot notation, and so on. However, the reference tree changes: the item in the source view becomes the child of the item in the reference tree of the target view, reversing the previous parent/child relationship. The only differences between the original item in the source view and that item as newly shared back into the source view is its placement in the reference tree and its Branch On Change status. That status is on or off, depending on the default setting for Branch On Change in the source view. The item in the target is identical to the item that was originally in the source, although its location has changed. It has the same properties and the same place in the reference tree.

For example, when an item M is shared from folder A to B, M is simply copied from A to B, creating M¹ in B as a child share of M. In a reverse-share from A to B, M is moved from A to B and then copied (shared) back to A, creating M¹ in A as a child share of M. This technique “transfers ownership” of the item from A to B.

An item is shared manually by performing a share (drag-and-drop) operation. An item is shared automatically when a child view is created. Shared items can branch. When an item is shared, either manually or automatically, from one location to another, the item in the new location has the same data, the same number of revisions, the same dot notation, and so on. However, a new reference to this item appears in the reference tree for this item. The only differences between the original item and the shared item are their locations and, perhaps, their Branch On Change status. That status is on or off, depending on the default setting for Branch On Change in the receiving view. Later, the Branch On Change status can be changed manually. When a shared item with its Branch On Change status is changed, it branches and the Branch On Change status is disabled.

A view that is compared with a target view, and whose changes are potentially merged to the target view. In some cases, the source view can use a rolled-back and/or read-only configuration.

The item types that are to be considered during a view compare/merge operation.

A view that is compared with a source view and which potentially receives changes from the source view. The target view must be able to be updated, and it must be a variant (branching) view or a non-derived (blank) view.