Reversing Bringover and Putback Transactions with Undo

You can reverse (undo) the action of the most recent Bringover or Putback transaction in a workspace by using the Undo Transactions window layout. You undo the Putback or Bringover transaction in the destination workspace (the one in which the files are changed). You can undo a Bringover or Putback transaction as many times as you like until another Bringover or Putback transaction makes changes in that workspace; only the most recent Bringover or Putback transaction can be undone.

If a file is updated or found to be in conflict by the Putback or Bringover transaction, the Undo transaction restores the file to its original state. If a file is "new" (created by the Bringover/Putback transaction), then it is deleted.

To initiate an Undo transaction:

1. Specify the workspace in which to reverse the transaction.

   If you select a workspace icon on the Workspace Graph pane prior to displaying the Undo layout, its name is automatically inserted in the Workspace Directory text box. You can insert a new path name followed by a Return, and edit and change the text box at any point.

2. Click Undo to initiate the transaction.

If you have selected Skip Backups in the Transactions window, you cannot undo the transaction.

Workspace Locks

When it is manipulating files in the specified workspace, Configuring obtains a write-lock for the workspace. Only a single write-lock may be in force at any time; no Configuring command may write to a workspace while a write-lock is in force. Lock status is controlled by the Codemgr_wsdata/locks file in each workspace. If Configuring cannot obtain the lock, it will display an error message and abort.

History File

Configuring records information regarding the Undo transaction in the Codemgr_wsdata/history file. This information can be useful as a means of tracking changes that have been made to files in your workspaces. Refer to "Viewing Workspace Command History" for further information regarding these files.

How the Undo Transaction Works

When the Bringover and Putback transactions update or create files in the destination workspace (the child in the case of Bringover, the parent in the case of Putback), they make backup copies of the originals before they actually make changes to the files. All existing files are copied to the Codemgr_wsdata/backup/files directory in the destination workspace, and the names of all newly created files are entered into a file called Codemgr_wsdata/backup/new.

When you decide that you would like to cause a workspace to revert to its state before a Bringover/Putback transaction, the Undo transaction does the following (see Figure 8-2):

• Copies the backed-up files from the Codemgr_wsdata/backup/files directory over the transferred files

• Deletes files whose names are contained in the Codemgr_wsdata/backup/new file

  The next Bringover/Putback transaction overwrites all data in the Codemgr_wsdata/backup directory.

  Figure 8-2 How the Undo Transaction Works

  
  

  ---

  Note -

  All files transferred by Configuring are under SCCS control. Usually, only SCCS history files are backed up during Bringover and Putback transactions; if the files are subsequently restored, the Undo transaction extracts the appropriate g-file (most recent delta) from the history file. If, however, a file in the child is checked out (using sccs edit) during the Bringover transaction (Configuring permits files to be checked out during a Bringover transaction, but not during a Putback transaction. If a file that is being put back is checked out, an error condition exists). Configuring backs up both the g-file and the SCCS history file in order to preserve the work in progress; the g-file and the SCCS history file are copied to the Codemgr_wsdata/backup/files directory and restored by the Undo transaction.

  ---