WorkShop Teamware: Solutions Guide: - Deleting Files From the Configuring Tool Workspaces

# Deleting Files From the Configuring Tool Workspaces |

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 behave (during bringover and putback transactions) as if the file has been newly created in the workspace's child or parent.

Take for instance, the following example. The file "C" is removed from the child workspace using the `rm` command.

Click for closeup.

Later, the bringover update transaction is used to update the child. Configuring examines the two workspaces and determines that the file "C" exists in the parent and not in the child -- following the usual Configuring rules, it creates "C" in the child.

Click for closeup.

The recommended method for "deleting" files in workspaces is to rename them out of the way using a convention agreed upon by everyone working on the project. Two possible methods are described below.

  1. Move deleted files to a "deletion" directory.

    Move (rename) files to an agreed upon directory that will be present in all the project's workspaces. For example:

        example% mv proj_ws/src/gui/module.c proj_ws/Deleted_Files/module.c.06.24.93
        example% mv proj_ws/src/gui/SCCS/s.module.c proj_ws/Deleted_Files/SCCS/s.module.c.06.24.93

    Click for closeup.

  It is important to ensure that the names of the files you move into this directory are made unique in some way so that deletions do not bump into each other. For example, if you delete files named `/ws/tape/driver/s.io.c` and `/ws/disk/driver/s.io.c`, by moving both to `/ws/Deleted_files/s.io.c`, Configuring only propagates the change of the last file moved.

  Two ways you can prevent this problem are:

- Append the date of the deletion to the file name (as in the example above).

- Move the full workspace-relative path name of the file beneath the `Deleted_Files` directory.

> Note - Remember to move both the SCCS history files and the g-files.

  Using this method, the Configuring tool:

- Moves the "deleted" files completely out of the source path

- Does not recreate the file

- Propagates the change throughout the workspace hierarchy as a rename, automatically "deleting" the file in all workspaces

  The file remains available to later reconstruct releases for which it was a part (for example, if it was part of a freezepoint -- see Versioning and Freezepointing User's Guide for more information about freezepoints1)

  2. Move deleted files to a special name in the same directory.

    Rename files you wish to "delete" so that they begin with some agreed upon prefix; for example the `.del-` prefix.

        example% mv module.c .del-module.c
        example% mv SCCS/s.module.c SCCS/s..del-module.c

    This method provides the benefits mentioned in Step 1, but keeps the file in the directory in which it originally resided.

1 The name "CheckPoint" has been changed to "FreezePoint."