test

Sun WorkShop TeamWare 2.1 User's Guide

Updating an Existing Child Workspace (Bringover Update)

You use the Bringover Update transaction to update an existing child workspace. You can display the Bringover Update layout of the Transactions window by any of the following methods:

The Bringover Update transaction transfers files that are under SCCS control. When a file exists in the parent workspace but not in the child, its SCCS history file is copied to the child and its g-file (the most recent delta) is created through the SCCS get command. When a file exists in both workspaces and has changed only in the parent, Configuring copies the new deltas from the parent to the child. When a file has changed in both workspaces, Configuring moves the child's new deltas into an SCCS branch.

To initiate a Bringover Update transaction:

  1. Specify the child workspace.

    If you select a workspace icon on the Workspace Graph pane prior to displaying the Bringover Update window, its name is automatically inserted in the To Child Workspace Directory text box. You can insert a 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 automatically inserted in the From Parent Workspace text box. The parent workspace name is retrieved from the Configuring metadata file Codemgr_wsdata/parent.

    Note -

    You can also specify the path name of directories that are not workspaces to import files and directories into the workspace.

    You can change a child workspace's parent for the duration of a single Bringover Update transaction by specifying the new parent's path name in the From Parent Workspace text field. 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 type the child workspace name and no icons are selected in the Workspace Graph pane, Configuring automatically updates the parent field if you reselect Bringover Update in the Category list box.

    Note -

    The parent and child workspaces must be accessible through the file system. Either automounter or NFS\256 mounts can be used. Accessibility (by users) to workspaces is controlled by the Codemgr_wsdata/access_control file in each workspace. Ensure that "bringover-to" and "bringover-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 Bringover Update 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 brought over. 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 Bringover 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 Force Conflicts checkbox to cause all updates to be treated as conflicts.

    • 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 child workspace and improves transaction performance, but it removes the option of using Undo.

  5. Click Bringover to initiate the transaction.

Action taken during the Bringover Update 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 Bringover Update 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-2 shows the different actions that Configuring takes when it encounters checked-out files.

Table 8-2 Effects of Checked-out Files on Bringover Update Transactions

File Checked-out in Parent 

File Checked-out in Child 

Configuring Action  

g-file and latest    delta differ 

 

oIssue a warning 

oProcess file 

g-file and latest    delta are identical 

 

oProcess file 

 

g-file and latest    delta are identical 

oUncheckout the file 

oProcess the file 

oCheckout the file 

 

g-file and latest    delta differ 

oCreate a conflict 

 

g-file is readonly 

oIssue a warning 

oDo not process the file 

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.

Conflicts

Bringover Update transactions often produce conflicts (when files are changed in both the parent and child). When this occurs, you are so notified by messages in the Transaction Output window. See Chapter 9, Resolving Conflicts," for details about resolving conflicts.

Workspace Locks

While files are read and examined in the parent workspace during the transaction, Configuring obtains a read-lock for that workspace. When Configuring manipulates files in the child 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 bring over files into a workspace that is locked, you will be so notified with a message that states the name of the user that has the lock, the command they are executing, and the time they obtained the lock. 

bringover: 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

Bringover Update transaction information is recorded 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.