Workspace

The workspace is the basis of the Configuring system. The workspace provides the isolation in which developers work concurrently with other developers programming in other workspaces. Project files are propagated between workspaces by Configuring commands. The workspace is a directory and its subdirectory hierarchy. When the workspace is created, Configuring creates a special subdirectory under the workspace, called Codemgr_wsdata, to store workspace information.

A Configuring project is created in a top-level workspace from which all others are derived. When other workspaces are created from the original workspace, the original file system hierarchy is recreated to form the new workspace. In the following example, work is begun by a developer in a workspace whose top-level directory is boatspex. The workspace exists under the directory /usr/src/ws.

Figure 3-1 Project File System Hierarchy

If you are assigned to work on the Boatspex project you create a copy of the original workspace in a file system of your choice; the workspace portion of the file system in the new workspace is identical to that of the original workspace. If you create the new workspace in your home directory, it appears something like Figure 3-2.

If you were only working on a portion of the project, you could copy only that portion.

Figure 3-2 Your New Workspace

The directories previous the workspace directory (boatspex) are variable. They change depending on where in the file system you locate the workspace. Below the workspace directory, the file system is a duplicate of the original workspace

Parent and Child Relationship

When you copy files from a workspace to create a new workspace, a special relationship is created between the original workspace and the new one. The original workspace is considered the parent of the newly created child workspace. You can acquire files from any Configuring workspace in this manner, and workspaces can have an unlimited number of children. The portion of the file system that you copy from the parent workspace is determined at the time you copy it. You can copy the entire contents of the parent to the child, making it a clone of the parent, or you can copy only portions of the file system hierarchy that are of interest to you. The Configuring transaction used to copy files from a parent workspace to a child workspace is called Bringover.

If you use the Bringover transaction to copy files to a workspace that does not already exist, the transaction creates a new child workspace and then copies files to it. This special case is called a Bringover Create transaction. You use the Bringover Update transaction to update an existing child workspace.

The parent and child relationship is special because project data is exchanged only between parent and child workspaces. All files contained in a child workspace were either brought over from a parent workspace or created in the child workspace. When development and testing are complete in the child, you can copy the files that were modified or added in the child back into the parent workspace. Once the altered files are present in the parent, they can be copied by other children or passed up another level to the parent's parent workspace. The Configuring transaction for copying files from a child workspace to a parent workspace is called Putback.

Unless the child is itself a parent, in which case new files can also be copied to it from its children.

Workspace hierarchies are formed by repeating Bringover transactions to create child workspaces. The hierarchy of parent and child workspaces forms a pathway through which data is moved throughout the project.

In the following example, a project is originally created in a workspace and then a three-level workspace hierarchy is created by means of the Bringover transaction. The original workspace is considered to be the parent of the integration workspace and, conversely, the integration workspace is considered to be the child of the original workspace. Developers (Jon, Jack, and Jill) then use the Bringover Create transaction, shown in Figure 3-3 to create child workspaces from the integration workspace, which forms a three-tiered hierarchy of workspaces.

Figure 3-3 Using the Bringover Create Transaction to Create a Workspace Hierarchy

In this hierarchy, files can be disseminated from Jon's workspace to its "sibling" workspaces owned by Jack and Jill. Jon uses the Putback transaction to copy modified files from his workspace into the common parent (step 1) and then Jack and Jill use the Bringover Update transaction to copy the files from the parent into their workspaces (step 2), shown in Figure 3-4.

Figure 3-4 Copying Files between Workspaces

Reparenting

Parent and child relationships can be changed. Configuring permits child workspaces to be "reparented" to new parent workspaces. Reasons that you might want to reparent a workspace include the following:

• To reorganize workspace hierarchies

• To populate a new project hierarchy (new top-level workspace)

• To move a feature into a new release

• To apply a bug fix to multiple releases

Refer to "Reparenting a Workspace"" for more information

Codemgr_wsdata Directory

Every Configuring workspace contains a directory named Codemgr_wsdata that is a subdirectory of the workspace top-level (root) directory. This directory contains text files that Configuring uses to log its actions, and store temporary and permanent data. You can view and alter these files using standard text utilities. Refer to "The Workspace Metadata Directory "" for more information.

Modifying Files

Since Configuring workspaces are simply directories within the SunOS file system, all your usual tools and utilities can be used on files and directories in workspaces. Your normal edit/compile/debug process is not altered by Configuring.