accurev patch [ -G ] [ -O ] [ -j <ver-spec> ] -v <ver-spec>
{ <element-list> | [ --from_stream=streamname ] -l <list-file> }
{ <element-list> | [ --from_stream=streamname ] -l <list-file> }
|
•
|
merge incorporates the entire set of changes between the from version and the common ancestor version.
|
|
•
|
patch incorporates just the set of “recent changes” in the from version. It determines this set of changes by starting at the from version and scanning backward through the file’s ancestry. The scan stops when it encounters a version that was originally created in another workspace, or a version that was promoted to another stream. This older version, termed the basis version, is judged to precede (and not belong to) the set of “recent changes” in the from version (which is also termed the head version).
|
You can use the -j option to suppress this automatic determination of the basis version, specifying a particular version to be used as the basis version.
Example 1: Before Mary started her recent work, she updated her workspace. This brought in a version of the file originally created by another user — say, version brown_dvt_john/5. Then she proceeded to create versions 5 through 7 in workspace brown_dvt_mary.
Derek decides to patch version brown_dvt_mary/7 into his workspace. AccuRev searches backward through the element’s ancestry, and includes the set of changes recently made in Mary’s workspace: this set includes brown_dvt_mary/5 through brown_dvt_mary/7; the patch doesn’t include the two versions created in workspace brown_dvt_john.
Example 2: Suppose Mary started by bringing version brown_dvt_john/6 into her workspace with an update. Then she created versions brown_dvt_mary/4 through brown_dvt_mary/6, promoted her work to the backing stream, and created two more versions: brown_dvt_mary/7 and brown_dvt_mary/8.
When John patches version brown_dvt_mary/8 into his workspace, AccuRev decides that only the versions since the promotion — versions 7and 8— contain “recent changes”. The idea is that a promotion typically marks the end of a programming task, not an intermediate checkpoint.
The Version Browser uses a dashed red line to indicate a version created by a Patch command. Selecting the version causes the set of versions included in the patch to be highlighted in red.
The basis version is recorded in the keep transaction that records a Patch command in the repository:
In this command, version 4/8 (brown_dvt_mary/8) was patched into version 5/9 (brown_dvt_john/9), and the result was kept as version 5/10 (brown_dvt_john/10). The backward search through the file’s ancestry identified 4/6 (brown_dvt_mary/6) as the basis version.
-I <issue-number>
Patch the contents of the change package of the specified AccuWork issue record. That is: for each change package entry indicated by an element argument, patch the entry’s head version into 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.
--from_stream=<stream_name>
-j <ver-spec>
-l <list-file>
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.
If you use this option, any <element-list> specified is silently ignored.
One or more element names, separated by whitespace. If you also specify a <list-file> using the –l option, this <element-list> is silently ignored.
-v <ver-spec>
Patch in the change that was finished in version 5/19 of foo.c, using version 4/6 as the basis version: