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