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 think that the file has been newly created in the workspace's parent or child.
Take for instance, the following example. The file "C" is removed from the child workspace using the rm command; 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.
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. One recommended method is to rename files you wish to "delete" so that they begin with the .del- prefix.
example% mv module.c .del-module.c example% mv SCCS/s.module.c SCCS/s..del-module.c |
For example:
This method has a number of advantages:
The file is no longer seen using default commands such as ls.
Configuring does not recreate the file.
Configuring propagates the change throughout the workspace hierarchy as a rename, "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 Chapter 5, Starting a Project" and Chapter 15, Preserving Project State With FreezepointingChapter 15, Preserving Project State With Freezepointing for more information about freezepoints).