test

Sun WorkShop TeamWare 2.1 User's Guide

Copying Files from a Child to a Parent Workspace (Putback)

All Configuring file transfer transactions are performed from the perspective of the child workspace; hence the Putback transaction "puts back" groups of files from the child to the parent workspace.

You use the Putback transaction to make the parent and child workspace identical with respect to the set of files that you specify for the Putback transaction. Use the Putback transaction after you make changes and test them in the child workspace. Putting the files back into the parent usually makes them accessible to other developers.

During a Putback transaction, Configuring may find that it cannot transfer files from the child to the parent workspace without endangering the consistency of the data in the parent. If this occurs, no files are transferred and the Putback transaction is said to be blocked. A Putback transaction is blocked because:

The Putback transaction transfers files that are under SCCS control. When a file exists in the child workspace but not in the parent, its SCCS history file is copied to the parent and its g-file (the most recent delta) is materialized through the SCCS get command. When a file exists in both workspaces and has changed only in the child, Configuring copies the new deltas from the child to the parent. When a file has changed in the parent, or both the parent and child, the Putback transaction is blocked.

Updating a Parent Workspace Using Putback

You can display the Putback layout of the Transactions window by any of the following methods:

To initiate a Putback transaction:

  1. Specify the child workspace.

    If you select a workspace icon on the Workspace Graph pane prior to displaying the Putback window, its name is automatically inserted in the From Child Workspace Directory text box. You can insert new path names, and edit and change the text box at any point.

  2. Specify the parent workspace.

    The name of the selected child's parent workspace is inserted in the From Parent Workspace text box. The parent workspace name is retrieved from the Configuring metadata file named Codemgr_wsdata/parent.

    You can change a child workspace's parent for the duration of a single Putback transaction by specifying the new parent's path name in the To Parent Workspace text box. You change the parent for that transaction only; if you wish to permanently change a workspace's parent, choose Edit > Parent in the Configuring main window or drag the child workspace icon over the new parent's icon. See "Reparenting a Workspace" for details regarding reparenting workspaces.

    Note -

    If you enter the child workspace name by hand and no icons are selected in the Workspace Graph pane, Configuring automatically updates the parent field if you reselect Putback in the Category list box.

    Note -

    The parent and child workspaces must be accessible through the file system. You can use either automounter or NFS mounts. Accessibility (by users) to workspaces is controlled by the Codemgr_wsdata/access_control file in each workspace. Ensure that "putback-to" and "putback-from" access for your workspaces are set appropriately. Refer to "Controlling Access to Workspaces" for more information.

  3. Create a list of directory and file names in the File List pane.

    You can copy all or part of the contents of the parent workspace to the child. You specify the directories and files you wish to copy in the File List pane. See "Specifying Directories and Files for Transactions" for information about specifying directory and file arguments.

    Note -

    If you are using your own FLPs to generate file lists, you also specify them in the File List pane.

    Note -

    If you specify relative path names for directory and file names, be aware that they are interpreted as being relative from the top-level (root) directory of the workspace hierarchy (which is assumed to be the same in both parent and child). If you specify these file names using absolute path names, the file must be found in one of the two workspaces or it will be ignored.

  4. Select options.

    • Select the Preview checkbox to preview the results of the transaction. If you invoke the Putback transaction with this option selected, the transaction proceeds without actually transferring any files. You can monitor the output messages in the Transaction Output window and verify the expected outcome of the transaction.

    • Select the Verbose checkbox to increase the information displayed in the Transaction Output window. By default, a message is displayed for each created, updated, or conflicting file. The Verbose option causes Configuring to print a message for each file, including those that are not put back. If both the Verbose option and the Quiet option are specified, the Quiet option takes precedence.

    • Select the Quiet checkbox to suppress the output of status messages to the Transaction Output window.

    • Select the Skip SCCS gets checkbox to inhibit the automatic invocation of the SCCS get command as part of the Putback transaction. Normally g-files are extracted from the SCCS history after they are brought over. This option improves transaction performance although it shifts the responsibility to the user to do the appropriate gets at a later time.

    • Select the Auto Bringover checkbox to cause Configuring to automatically start a Bringover Update transaction to update files in the child if the Putback transaction is blocked.

    • Select the Skip Backups checkbox to skip the step of copying the existing files to the Codemgr_wsdata/backup/files directory in the destination workspace. This option reduces the disk space occupied by the parent workspace and improves transaction performance, but it removes the option of using Undo.

  5. Type a comment.

    Type a comment that describes the Putback transaction. This comment is included with the transaction log written into the file called Codemgr_wsdata/history in the parent workspace. The comment can be up to 8 Kbytes long.

  6. Click Putback to initiate the transaction.

Action taken during the Putback transaction can be reversed using the Undo transaction. Refer to "Reversing Bringover and Putback Transactions with Undo " for details.

Checked-out files

When, during a Putback transaction, Configuring encounters files that are checked-out from SCCS, it takes action based on preserving the consistency of the files and any changes to the file that might be in-process.

Table 8-4 shows the different actions that Configuring takes when it encounters checked-out files.

Table 8-4 Effects of Checked-out Files on Putback Transactions

File Checked-out in Parent 

File Checked-out in Child 

Configuring Action 

g-file and latest    delta differ 

 

oBlock Putback transaction 

 

g-file and latest    delta are identical 

   or g-file does not    exist) 

 

oUncheckout the file 

oProcess the file 

oCheck-out the file  

 

g-file and latest    delta differ 

oBlock Putback transaction 

 

 

g-file and latest    delta are identical 

oProcess the file 

 

g-file does not exist 

oIssue a warning 

oProcess the file 

oNo changes made 

Transaction Output Window

As the transaction proceeds, status information is displayed in the Transaction Output window. Messages are displayed as files are processed during the transaction, and a transaction summary is displayed when execution is completed.

Workspace Locks

While files are read and examined in the child workspace during the transaction, Configuring obtains a read-lock for that workspace. When Configuring manipulates files in the parent workspace it obtains a write-lock.

Read-locks may be obtained concurrently by multiple Configuring commands that read files in the workspace; no commands may write to a workspace while any read-locks are in force. 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 you attempt to put back files into a workspace that is locked, you are notified with a message such as the following that states the name of the user that has the lock, the command they are executing, and the time they obtained the lock. 

putback: Cannot obtain a write lock in workspace "/tmp_mnt/home/my_home/projects/mpages"
because it has the following locks:
	Command: bringover (pid 20291), user: jack, machine: holiday, time: 12/02/91 16:25:23
  (Error 2021)

History File

Putback transaction information is recorded in the file called Codemgr_wsdata/history. 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.

Putback Action Summary

Table 8-5 summarizes the actions that Configuring takes during Putback transactions.

Table 8-5 Summary of Configuring Actions During a Putback Transaction

File in Parent 

File in Child 

Action by Configuring 

Exists 

Does not exist  

Block Putback and notify user 

Does not exist 

Exists 

Create the file in the parent 

Unchanged 

Unchanged 

None 

Unchanged 

Changed 

Update file in the parent. (Merge SCCS files and extract [via get] a g-file that consists of the most recent delta.)

Changed 

Unchanged 

Block Putback, notify user. 

Changed 

Changed 

Block Putback, notify user. 

Checked out 

Checked out* 

Block Putback, notify user. 

Unresolved conflict 

Unresolved conflict** 

Block Putback, notify user. 

*If a file is checked out in either the parent or the child, the transaction is blocked. See Table 8-4 for more information about putting back files that are checked out.

**If a conflict is unresolved in either the parent or the child, the transaction is blocked.