accurev revert -t <transaction-number> [ -G ] [ -K ] [ -S
<stream> ]
[ -I :
<issue-number> ] [ -3 ] ]
The revert command provides an “undo change” capability for dynamic streams. You have the choice of specifying a “traditional” revert operation, which requires you to be in a workspace based on that stream, or a “direct” revert operation, which does not require a workspace.
The “direct” revert takes fewer steps, but since it places the results of the
revert directly into a stream, it is best used in simpler scenarios, or in a stream that does not propagate immediately to other users. For more complicated scenarios, where you want to test the results of the
revert, it is better to use the workspace-based “traditional”
revert.
revert doesn't actually remove any versions from the stream or transactions from the repository; that would be a violation of AccuRev's TimeSafe principle. Instead,
revert creates a new version (using
keep) of one or more elements. For a traditional
revert, this
keep is peformed in your workspace; for a direct
revert, the
keep is done within the stream. If the version being reverted is the first version in a stream, the command
defuncts that element.
NOTE: You cannot direct revert an initial version, unless there are no other changes in the backing stream. This means that you cannot revert the first version of a file if someone else has already made changes to it. You cannot defunct a file that someone else edited because it would not be possible to then add their edits back into the non-existent file.
The “subtracting out” of content changes is performed by the same tool that performs a content-level
merge. Submitting a different set of versions to this tool effectively implements a “reverse patch” algorithm (see below).
The revert command also “subtracts out” namespace changes. If the file name and/or parent directory were changed by the issue/transaction being reverted, and no one has moved or renamed the file since this issue/transaction, AccuRev moves the file back to its pre-issue/transaction directory and give it back its old name.
After a traditional revert command completes, you can verify the correctness of its work (and make further changes, if appropriate) in the workspace. Then, you can complete the “undo change to stream” process by promoting the new versions.
A direct revert promotes its changes directly into the specified stream. However, we recommend that you still build and test these changes in an updated workspace to verify the results.
In a revert command, the changes in a specified set of versions are removed from a stream's current versions of those elements:
For each element it processes, the revert command uses the same tool as the
merge command to perform the operation that removes a set of content changes from the current version. We use the term “reverse patch” to describe this process, but it's really just another instance of effectively modifying the merge algorithm by switching around the versions.
•
|
For revert by transaction, AccuRev determines the version that was in the stream just before the current version was promoted there; this version is designated to be the “to version”. For revert by issue, the common ancestor is the issue basis, and the “to version” is the issue head.
|
Just as with the merge command, you can use environment variable
AC_MERGE_CLI to configure an alternative merge tool. See
User Preferences on page 156.
revert finishes its work by invoking the
keep command to preserve the results of the merge (reverse patch) operation.
In this algorithm's switching around of the versions, the basis version of the change package entry becomes the direct ancestor of the newly created version. This listing of the final keep transaction shows the result of removing a change package entry whose head version is 9/14 and whose basis version is 9/17.
The “reverted from” data indicates that the changes made between versions 9/17 and 9/23 were added to the common ancestor version, 9/14. This is equivalent to
subtracting the changes in the change package entry (9/14 - 9/17) from the current version, 9/23.
AccuRev does not have a command to revert a purge operation. However, you can use the procedure documented at the
purge command. In the
CLI User’s Guide, see
To undo a purge on page 207.
-I <issue-number>{:<
issue-number>}
For a typical revert operation,
-I <issue-number> specifies the issue record whose change package is to be reverted. Specifying the second issue number (
-I <issue-number>:<issue-number>) allows you to save a step by indicating what target issue will record the revert changes. You should create this issue prior to performing the
revert. (It is possible to specify an existing issue for the destination, but you should only do this if you know exactly what you are doing.) When performing a “traditional”
revert, which requires the use of a workspace, you must specify either
-t or
-I, but not both. One exception to this is that you can specify a destination issue only (preceded by a colon), as in “
-t 2023
-I :1004”. When performing a direct
revert, you can specify the full
-I (specifying both source and destination issue numbers) with
-S.
Specifies that the <issue-number> specified by the
-I switch is a third-party ITS key rather than an AccuWork issue number.
“Undo” promote transaction 489, by subtracting the recent changes in the versions promoted by that transaction.
Use a “direct” revert operation to undo the changes recorded in the change package of issue record #2763 in stream prod1_0_itr, and recording the revert changes in issue #2891:
Use a “direct” revert operation to undo the changes recorded in the change package of issue record #15 in stream prod1_0_itr. AccuRev will prompt you for the issue to record the revert changes: