The Merge command can merge changes made to element in two different contributor Either of two versions of an element, which are to be combined in a merge operation, producing a new version of the element. This can involve both content changes and namespace changes. versions.
The basic procedure for handling changes in a merge operation is the same for all elements, including link elements:
At the time of the merge, one contributor is located in a workspace, where the new version will be created); the other contributor is the version in the workspace's backing stream (parent stream, basis stream) The stream that is just above a given workspace or stream in a depot's stream hierarchy. The given workspace/stream inherits versions from the backing stream. or some other dynamic stream A stream whose configuration changes over time, with new versions promoted from child workspaces and/or from other dynamic streams. It also inherits versions from its parent stream.. (You might have specified this second version as part of a particular transaction A record in the AccuRev repository database that indicates a particular change: promoting of a set of versions, changing the name of a stream, modification to an issue record, etc. Each transaction has an integer transaction number, which is unique within the depot. or change package A set of entries, each in the form of a basis-version/head-version pair, recorded on the Changes tab of an issue record. The change package records the changes to one or more elements, made to implement the feature or bugfix described in that issue record. Each entry in the change package describes changes to one element: the changes between the basis version and the head version. See patch..)
If just one contributor makes a change from the contributors' closest common ancestor (of two versions of an element) The most recent version that is an ancestor of two specified versions. Used in a merge operation to minimize the amount of work required to combine the contents of the two specified versions. See merge, version graph., AccuRev incorporates the change into the new, merged version automatically.
If both contributors make a change from the contributors' closest common ancestor, AccuRev regards this as a conflict See conflicting change., which you must resolve during the merge process.
For a more detailed discussion, in the context of changes to the contents of a text file, click here.
Given that the algorithm for handling changes is basically the same for all elements, the only thing special about merging versions of a link is the nature of changes to a link element.
AccuRev tracks namespace changes to a link:
Initial creation of the link. [note ]
Renaming the link.
Moving the link to another location in the depot's directory tree.
Each of the above changes creates a new version of the link element.
AccuRev also tracks changes to the contents of a link -- that is, changes to the link's target element (for an element link (element-link element) An element whose contents is a pointer to another element, which must be in the same depot. The target element can be a directory element, a file element, another element link, or a symbolic link.) or to the link's target pathname (for a symbolic link (symbolic-link element) An element whose contents is a pathname. The pathname can point to AccuRev data (that is, a location inside a workspace) or non-AccuRev data.). Each such change creates a new version of the link element.
Execution of the Merge command on a link element never involves the Merge tool (or third-party tool), which is designed to process the contents of text files. A conflict at the content-level merge is handled by a link-specific dialog:
A conflict at the namespace-level merge involves making choices in the same one or two dialogs used for all kinds of elements.