Copying Files between Workspaces |
8 |
 |
The chapter covers the following topics:
|
Copying Files from a Parent to a Child Workspace (Bringover) | |
An example demonstrating these transactions can be found in Chapter 12, "Configuring Example" on page 143.
Configuring Transaction Model
Configuring is designed so that all interworkspace transactions (Bringover Create, Bringover Update, Putback, Undo, and Resolve) are based upon the same user model; that model is described in Figure 8-1. The ways in which the transactions differ are described later in this chapter (the Resolve transaction is described in Chapter 9, "Resolving Conflicts").
Figure 8-1 Configuring Transaction Model
General File Copying Information
This section contains background information about copying files between workspaces. SCCS History Files
When considering Configuring file transfer transactions, it is important to remember that source files are actually derived from SCCS deltas and are identified by SCCS delta IDs (SIDs). When a file is said to be copied by either a Putback or Bringover transaction, Configuring actually acts upon (copies or merges) the file's SCCS history file (also known as the "s-dot-file").
Viewing Transaction Output
Output from Configuring transaction commands is viewed in the Transaction Output window. This window is activated automatically when you invoke one of the transactions. You can also activate it yourself by choosing the Show Output button in any of the Transactions window layouts. Check the online Help for details on TeamWare windows.
Note - Configuring transactions are implemented through command-line based programs; some portion of the output contains messages related to the command-line implementation. This manual describes only messages that apply to the actual transactions. If you are interested in more information about the underlying command-line based programs, please refer to the appropriate man pages.
Specifying Directories and Files for Transactions
When you copy files between parent and child workspaces using the Bringover and Putback transactions, you must specify the directories and files you wish included in the transaction. The Bringover Create, Bringover Update, and Putback layouts of the Transactions window contain a File List pane. The File List pane is a scrolling text window in which you construct the list of file and directory names to be included in the transaction. You can accept the default "." convention to bringover or putback all files in a workspace. Grouping Files for Transfer Using File List Programs
In addition to explicitly specifying files for transfer, you can execute programs that generate that list for you -- such a program is called a File List Program (or FLP). An FLP generates a list of files to stdout; the Bringover and Putback transactions read the list of files from stdout and include them in the transaction.
Note - You can create your own FLPs that generate lists of files that are useful for your project.
Constructing Directory and File Lists in the File List Pane
Configuring attempts to provide you with a useful initial list of directories and files in the File List pane. You are free to modify the list in any way you wish. The initial list is constructed differently for each type of transaction:
Every workspace contains a Codemgr_wsdata/args file that is maintained by the Configuring Bringover and Putback transaction commands. The args file contains a list of file, directory, and FLP arguments. Initially, the args file contains the arguments specified when the workspace was created. If you explicitly specify arguments during subsequent Bringover or Putback transactions, Configuring determines if the new arguments are more encompassing than the arguments already in the args file; if the new arguments are of a wider scope, the new arguments replace the old.
Note - You can edit the args file at any time to change its contents.
Selecting Files in the File List Pane
Once a list of files and directories exists in the File List pane, you can include or exclude any of them for a given transaction. To be included in a transaction, the file or directory name must be selected. You can select or deselect any number of names by moving the pointer over them and clicking SELECT. You can select or deselect the entire list by choosing the Select List or Unselect List items from the Edit menu. Loading and Saving Default Lists
You can reload the default list from the workspace args file at any time by choosing the "Load List from Defaults" item from the File menu. This feature is useful if you find that you've made changes to the list that you do not want to keep; you can use Load List from Defaults to revert the list to its default state. Changing the Contents of the File List Pane
You add files and directories to the File List pane by using the point-and-click, Configuring Chooser. See "Add Files Chooser" on page 88 for details.
You delete files and directories from the File List pane using:
Note - You can specify the "." directory as the sole item in the file list to designate that the entire workspace be copied to the child. Enter the "." character using the Name text field in the Configuring Chooser.
Use the chooser to navigate down through the file system hierarchy by double-clicking SELECT on any directory icon. Double-click SELECT on the directory icon to move hierarchically upward in the file system. To move directly to a directory, enter its path name in the Name text field and select the Load Directory button.
Note - The Configuring Chooser is also used to add FLPs to the File List pane. The appropriate version of the chooser is automatically invoked when you change the File List pane mode using the abbreviated menu immediately above the pane.
To add a file or directory to the File List pane:
Note - The chooser does not permit you to navigate outside of the workspace file system.
Note - A check mark in a file icon indicates that the file is checked out from SCCS.
Note - You can use the Bringover Update and Create transactions to import directories and files from directories that are not Configuring workspaces. You cannot Putback files to directories that are not workspaces.
Creating a New Child Workspace (Bringover Create)
You use the Configuring Bringover Create transaction to copy groups of files from a parent workspace to a child workspace that is created as a result of the Bringover transaction. You can display the Bringover Create layout of the Transactions window by any of the following methods:
To initiate a Bringover Create transaction, follow these five basic steps:
Note - You can also specify the path name of directories that are not workspaces to import directories and files into the new workspace.
Note - If you are using your own FLPs to generate file lists, you also specify them in the File List pane. Refer to the Sun WorkShop TeamWare: Solutions Guide for examples of how to use CodeManager FLPs.
Update item from the Transactions menu.
Update item from the Workspace Graph pane pop-up menu.
To initiate a Bringover Update transaction follow these five basic steps:
Note - You can also specify the path name of directories that are not workspaces to import files and directories into the workspace.
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 rechoose the Bringover Update item in the Category menu.
Note - If you are using your own FLPs to generate file lists, you also specify them in the File List pane.
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.
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 rechoose the Putback item in the Category menu.
Note - If you are using your own FLPs to generate file lists, you also specify them in the File List pane.
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, follow these three basic steps:
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:
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.
The best way to delete and rename files is to use the move and delete commands available from the Workshop Versioning menu. This section describes the underlying process.
Note - For the purposes of this discussion, the terms "rename" and "move" are considered to be the same action and are referred to only as "rename."
For example, in the following figure, the name of file C in the parent is changed to D. When Configuring brings the file over to the child it must decide which of the following is true:
The action that Configuring takes is very different in each case. If it is a new file in the parent, Configuring creates it in the child; if it has been renamed in the parent, Configuring renames file "C" to "D" in the child.
Configuring stores information in the SCCS history files that enables it to identify files even if their names are changed. You may have noticed the following message when viewing Bringover and Putback output:
Examined files: |
Configuring examines all files involved in a Bringover Update or Putback transaction for potential rename conditions before it begins to propagate files.
rename from: old_filename to: new_filename |
Name History
Configuring stores information about a file's name history in its SCCS history file. The name history is simply a list of the workspace-relative names that have been given to the file during its lifetime. This information is used by Configuring to differentiate between files that have been renamed and those that are new. When you rename a file, Configuring updates the file's name history during the next Bringover or Putback transaction that includes it. When a name history is updated, you are notified in the Transaction Output window.
Names Summary: 1 updated parent's name history 1 updated children's name history |
Rename Conflicts
In rare cases, a file's name is changed concurrently in parent and child workspaces. This is referred to as a rename conflict. For example, the name of file "C" is changed to "D" in the parent, and concurrently to "E" in the child.
Figure 8-3 File "C" is Concurrently Renamed in both Parent and Child Workspaces
rename conflict: name_in_child rename from: name_in_child to: name_in_parent |
Deleting Files
Deleting files from a Configuring workspace is a little trickier than it first appears. Deleting a file from a workspace with the rm command causes Configuring to think that the file has been newly created in the workspace's parent or child.
Figure 8-4 File "C" Is Removed From The Child Using the rm Command, Then
Created Again by Bringover
example% mv module.c .del-module.c example% mv SCCS/s.module.c SCCS/s..del-module.c |
For example:
This method has a number of advantages:
Preview
Verbose
Quiet
Skip SCCS gets
Force Conflicts
Issue a warning
Preview
Verbose
Quiet
Skip SCCS gets
Force Conflicts
Preview
Verbose
Quiet
Skip SCCS gets
Auto Bringover
