Revert to...

•

Revert to Basis would replace the version of foo_3.java in the workspace tree (the current workspace version, which may or may not be the Most Recent Version) with the version from the backing stream based on the last time workspace was updated. In this example, this is its basis version, prod3000_itr/1, not the current version in the backing stream (prod3000_itr/2), which could potentially cause your local build to fail. Think of this command as “Revert to Last Update Version”.

•

Revert to Most Recent Version would replace the modified version in your workspace tree with the last kept version (i.e., it would replace the version of foo_3.java in the workspace tree with the latest version from the workspace stream, prod3000_itr_user1/4.)

A Revert to Basis operation on the current version in the prod3000_itr dynamic stream (prod3000_itr/2) would cause foo_3.java to become inactive in the stream. This would result in the prod3000_itr stream inheriting the version from its parent stream. (It is not replaced with the previous version in the stream, prod3000_itr/1.) To "undo" a promote or purge operation, a Revert from the History Browser (or a CLI revert command) is issued specifying the transaction number. This creates new kept versions that are minus the set of changes promoted in the specified transaction. These kept versions must then be promoted to complete the undo (reverse merge) operation.