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.

  ---