accurev merge [ -v <ver-spec> ] [ -G ] [ -K ]
[ -O ][--use_time_basis_for_overlap]{ [ -Fx ] -l
<list-file> |
<element-list>}
accurev merge [-I <issue-number> [-3] ][--use_time_basis_for_overlap]{ [ -Fx ] -l
<list-file> |
<element-list> }
The merge command edits your workspace’s copy of an element by combining its contents with the contents of the version currently in the backing stream. This command can also change the name of the element, if its name in the backing stream differs from its name in your workspace. These two kinds of changes are termed
content changes and
namespace changes, respectively.
Variations: you can use the -v option to specify another stream’s version (instead of the backing stream’s version) as the
from version; and you can use the
-s option to merge to a stream other than your workspace stream.
AccuRev uses a 3-way merge algorithm: it considers the
from and
to versions, along with a third version: the
closest common ancestor of these two versions. It determines this common ancestor by analyzing the stream hierarchy and taking into account previous merges for the element. (It does not take into account any
patch commands you may have executed to incorporate other people’s changes into your version.) Thus, if you perform frequent merges on a file, you need to merge only the changes that have occurred since the last merge. You don’t have to consider all the changes back to the point at which the two versions diverged.
merge reports the three versions being considered, reporting each one in stream-number/version-number format:
Performing the Namespace Merge. If a namespace merge is required,
merge prompts you to choose one of the names:
Performing the Content Merge. If a content merge is required,
merge creates a temporary “merged file”, containing:
Non-conflicting changes are automatically inserted into the merged file. A change is non-conflicting if
one of the contributors — either the “from” version or the “to” version — changed the content at that point in the file, but the other contributor didn’t make a change. (If exactly the same change was made in both contributors, that’s non-conflicting, too.)
A conflicting change occurs where
both contributors contain a changes from the common ancestor. In this case,
merge inserts both the “from” and “to” text sections into the merged file, along with separator lines:
<<<<<<< Your_Version (separator: start of conflict section)
text in "to" version"
text in "to" version"
text in "to" version"
====
(separator)
text at same location in "from" version"
text at same location in "from" version"
>>>>>>> Backing_Version
(separator: end of conflict section)
After creating the merged file, merge asks what you want to do next:
Overwrite the to version (the file in your workspace) with the current contents of the merged file; then
keep a new version of the element in your workspace stream. If you haven’t edited the merged file, it may include conflict sections with separator lines, as shown above.
After you end the edit session, merge prompts you again to take an action. This time, “keep” is the default.
|
•
|
Use the copy in your workspace. Execute a merge command, and choose to keep the result. This keeps the copy in your workspace, and records a merge from the backing-stream version to your newly-kept version.
|
|
•
|
Use the backing stream version. Execute a purge command. This resolves the overlap by removing the element from your workspace stream. Your workspace reverts to having a copy of the backing stream’s version of the element.
|
Use the stat -o command to list the elements that need to be merged before you can promote them to the backing stream. This lists all the elements whose changes in your workspace overlap changes in the backing stream.
The update command performs its work on all the elements in your workspace. Sometimes, however, you may want to update just a selected set of elements to the versions currently in the backing stream. You can use a series of
merge commands to do so. For example, if your backing stream is named
gizmo_dvt and you want to update elements
foo.c,
bar.c, and
read.me, this set of commands accomplishes the “partial update”:
|
•
|
AC_MERGE_CLI: An environment variable used by merge to invoke an alternative merge program. (The default merge program is acdiff3 in the AccuRev bin directory.) The command string must specify all four files involved in the merge, using these substitution patterns:
|
%a% or
%a — Filename of the common ancestor version.
%1% or
%1 — Filename of the version in the backing stream (or other non-workspace version).
%2% or
%2 — Filename of the version in the workspace.
%3% or
%3 — Title to be displayed for the common ancestor version.
%4% or
%4 — Title to be displayed for the version in the backing stream (or other non-workspace version).
%5% or
%5 — Title to be displayed for the version in the workspace.
%o% or
%o — Merge results (output) file.
The values that AccuRev substitutes for the %3%,
%4%, and
%5% patterns are
not enclosed in double-quotes, even though the values typically include
SPACE characters. The values that AccuRev substitutes for the other patterns
are enclosed in double-quotes.
(implies -i) Considering the entire
backing chain of the workspace’s version, list each version that requires a merge with its parent version. This is similar to
stat -B, but lists only the versions with
overlap status.
Merge the contents of the change package of the specified AccuWork issue record. That is: for each change package entry indicated by an element argument, merge the entry’s head version with your workspace version.
Specifies that the <issue-number> specified by the
-I switch is a third-party ITS key rather than an AccuWork issue number.
Use the workspace's update level or the stream's time basis to identify overlap instead of using the current time.
Process the elements listed in <list-file>. This must be a text file, with one element name per line. Extra whitespace is not allowed; make sure there are no empty lines and no leading or trailing white space around the filenames. Wildcards are not expanded. There is no provision for comment lines in the file.
Signals that <list-file> (see the
-l option) is an XML-format file, not a flat text file. Example:
<workspace eolType="1"/>
<element
type="2" # 1-directory, 2-text, 3-binary, 4-ptext, 5-element link, or 6-symbolic link
option1="3"
# parent directory - see below for values
option2="1"
# parent eid
option3="3"
# element name - see note below for values
option4="\.\cc.txt"
# backing name
option5="\.\c"
# ancestor name
option6="14"
# eid of element you are merging
option7="C:\DOCUME~1\rtitle\LOCALS~1\Temp\merge60341.tmp">
# temp file
option8="3"
# link target - see below for values
</element>
Merge in the changes to file foo.c from the backing stream:
Merge in the changes to file foo.c from the maintenance stream:
After saving the results of your changes, select the keep option from the menu to keep the changes and save a record of the merge. If you merged elements against the backing stream in order to be able to promote your changes, you can now
promote the merged elements.