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