Merge: When Changes Would Collide

The preceding sections on the Promote and Update commands both discuss the situation in which two users concurrently work on the same file. Their changes to the file are said to overlap. Both Promote and Update decline to process a file with (overlap) status because doing so would cause one user’s changes to overwrite another’s changes. For example:

Team members John and Mary both Keep one or more new private versions of logic.xml in their respective workspaces.
Mary Promotes her latest new version of logic.xml to the backing stream.
At this point, AccuRev:
- Will not allow John to Promote his version of logic.xml to the backing stream (there is no reason to assume that John’s changes should take precedence over the changes Mary has already made and promoted).
- Will not overwrite John’s copy of logic.xml when he updates his workspace (again, AccuRev does not assume that a version in the backing stream should take precedence over changes made to the version in the workspace). The Update command skips over this file, but continues its work on other files.
- Flags the overlap condition by highlighting logic.xml in yellow.

Before John can either promote or update logic.xml, he must incorporate, or merge, the version in the backing stream, which contains Mary’s changes, into his own copy of the file. The Merge command is essentially a text editor, which combines the contents of two versions of a text file. The resulting merged version replaces the file in John’s workspace.

This figure shows how to run the Merge command from the File Browser toolbar. Merge is also available from the Actions and context (right-click) menus.

Tip: Use the File Browser Conflicts mode to view overlap and other conditions that prevent files from being updated and promoted.

Often, a merge operation is unambiguous, and so can be performed automatically. For example, suppose Mary’s changes to file logic.xml all occur in lines 30–50, and all of John’s changes occur in lines 125–140.

In this case, merging the two versions involves replacing some or all of John’s 20 lines with Mary’s. Now, the edited version of logic.xml in John’s workspace contains both users’ changes.

Note: We do not claim that the two sets of changes are semantically consistent with each other. That is what the build-and-test cycle is for!

If both John and Mary have made changes to the same part of the file, say, lines 2-10, then John must decide how to resolve this conflict. The graphical Merge tool makes this easy.

After performing a merge, AccuRev automatically Keeps the merged version to preserve the results of the merge operation. You can then Promote the merged version to the backing stream. After that, other team members can use Update, perhaps in conjunction with Merge, to bring all the changes into their workspaces.

More About Merge

The graphical Merge tool performs a three-way merge, which uses the common ancestor of the two versions being merged. This algorithm helps to automate the merge operation, often completely eliminating the need for human intervention. AccuRev performs merge operations on text files only. Binary files are merged by choosing which version to take.

AccuRev keeps track of all merge operations. This greatly simplifies subsequent merge operations on files that have been merged previously: you do not need to resolve the same conflicts over and over again.

The most common overlap situation happens when AccuRev prevents you from promoting a file, because someone else "got there first" in creating a version in the backing stream. AccuRev can also detect deep overlaps, in which another user "got there first" in creating a version in the parent of the backing stream, or in other higher-level streams.