Reparenting a Workspace

As discussed in Chapter 3, Introduction to TeamWare Configuring, the parent/child relationship is the thread that connects the workspace hierarchy. Configuring provides the means for you to change this relationship at your discretion.

This section discusses how you can explicitly change a workspace's parent. It is also possible for you to implicitly change a workspace parent "on the fly" (for the duration of a single command) by specifying the new parent's path name as part of a Bringover Update or Putback transaction. See the descriptions of the Bringover Update and Putback transactions in Chapter 8, Copying Files between Workspaces" for more information.

Two Ways to Reparent Workspaces

This section describes two equivalent ways to reparent workspaces.

Drag and Drop Workspace Icons

You can change a workspace's parent by selecting its icon in the Workspace Graph Pane, pressing and holding the SHIFT key, and dragging it on top of its new parent's icon. The display is automatically adjusted to reflect the new relationship.

You are prompted to confirm the change.

You may also "orphan" a workspace by selecting its icon, pressing SHIFT, and dragging it to an open area on the Workspace Graph pane. The workspace no longer has a parent: the display is automatically adjusted to reflect its new status.

The Parent Command

You can change a workspace's parent by selecting its icon in the Workspace Graph pane and then choosing Edit > Parent.This opens the Parent dialog box.

When the window is initially opened, the New Parent Workspace Directory text box contains the name of the current parent. Edit that line so that it contains the name of the new parent file and click the Parent button. The Workspace Graph pane is automatically adjusted to reflect the new relationship.

If you do not specify a parent workspace in the New Parent Workspace Directory text box, the workspace is orphaned--it has no parent. The Workspace Graph pane is automatically adjusted to reflect its new status.

Reasons to Change a Workspace's Parent

You might want to permanently or temporarily change a workspace parent for any of these reasons:

• To populate a new project hierarchy (new top-level workspace). You may be completing Release 1 of your product and see the need to begin work on Release 2. In this case you might:

  • Create a new (empty) Release 2 workspace by means of File > Create Workspace

  • Use either of the two methods described in "Two Ways to Reparent Workspaces" to make the Release 2 workspace the new parent of the Release 1 workspace

  • Use the Putback transaction to copy files to the Release 2 workspace

  • Reparent the Release 1 workspace to its original parent

• To move a feature into a new release. If a feature intended for a particular release is not completed in time, the workspace in which the feature was being developed can be reparented to the following release's integration workspace. A similar use of reparenting is described in the example in the"A Reparenting Example".

• To apply a bug fix to multiple releases.The workspace in which work was done to correct a bug is reparented from hierarchy to hierarchy; the Configuring Putback transaction is used to incorporate the changes into the new parent. An example of this use of reparenting is included in "A Reparenting Example".

• To reorganize workspace hierarchies

  • You can add additional levels to the hierarchy.

  • You can remove levels from the hierarchy (do not specify a new parent during reparenting).

  • You can reorganize workspace branches within the project hierarchy.

• To adopt an orphan workspace if its Codemgr_wsdata/parent file is deleted. If, for some reason a file is orphaned (for example, its parent is corrupted or its own Codemgr_wsdata/parent file deleted) you can use the reparenting feature to restore its parentage.

A Reparenting Example

Often a bug is fixed in a version of a product and a patch release is made to distribute the fixed code. The code that was fixed must usually be incorporated into the next release of the product as well. If the product is developed using Configuring, the patch can be incorporated relatively simply by means of reparenting.

In the following example, a patch is developed to fix a bug in Release 1.0 of a product. The patch must be incorporated into Release 2.0, which has begun development.

1. The workspace in which the patch was developed (or the workspace from which it is released) is cloned by means of the Bringover Create transaction. The reason the workspace is cloned is that it will be altered by its interaction with its new parent (Bringover transaction to synchronize it with its new parent).

2. Either of the two reparenting methods are used to change the cloned workspace's parent from 1.0patch to 2.0. (see Figure 7-1).

   Figure 7-1 Patch Workspace Reparented to New Release

   
   

3. The workspace is then updated from its new parent, and any new work is brought over from 2.0. (see Figure 7-2A).

4. The fixes made for the patch are merged in patch with the files from 2.0 and are put back into the 2.0 workspace where they are now available to workspace 2.0child. (see Figure 7-2B).

   Figure 7-2 Files Brought Over, Merged, and Incorporated into the New Release

   
   

5. Files are brought over to 2.0child, and patch is deleted by means of Edit > Delete > Sources and Codemgr_wsdata Directory. (Figure 7-3).

Figure 7-3 Patched Files Brought Over into 2.0child; patch Deleted