test

Sun WorkShop TeamWare 2.1 User's Guide

Renaming, Moving, or Deleting Files

When you rename, move, or "delete" files, Configuring tracks those changes so that it knows how to manage the altered files during Bringover and Putback transactions. Although Configuring processes these files automatically, it is helpful for you to understand some of the ramifications of renaming, moving, or deleting files.

Note -

For the purposes of this discussion, the terms "rename" and "move" are considered to be the same action and are referred to only as "rename."

The best way to delete and rename files is to use the move and delete commands available from the TeamWare Versioning menu. This section describes the underlying process.

Renaming Files

When you bring over or put back files that you (or another user) have renamed, Configuring must decide whether the files have been newly created or whether they existed previously and have been renamed. When you rename a file, you must rename both the g-file and the SCCS history file. Configuring propagates the name change throughout the workspace hierarchy using the same rules used with file content updates and conflicts.

During transactions, Configuring processes files individually. When you rename a directory, each file in the directory is evaluated separately as if each had been renamed individually.

Renaming Example

In Figure 8-3, the name of file C in the parent is changed to D. When Configuring brings the file over to the child it must decide which of the following is true:

Figure 8-3 File "C" Renamed to "D"

Graphic

If the same case was the subject of a Putback operation, the same problem would apply: Is "C" new in the child, or has it been renamed from some other file?

The action that Configuring takes is very different in each case. If it is a new file in the parent, Configuring creates it in the child; if it has been renamed in the parent, Configuring renames file "C" to "D" in the child.

Configuring stores information in the SCCS history files that enables it to identify files even if their names are changed. You may have noticed the following message when viewing Bringover and Putback output:

 Examined files:

Configuring examines all files involved in a Bringover Update or Putback transaction for potential rename conditions before it begins to propagate files.

When Configuring encounters renamed files, it propagates the name change to the child in the case of Bringover, and to the parent in the case of Putback. You are informed of the change in the Transaction Output window with the following messages: 

rename from: old_filename
         to: new_filename

Name History

Configuring stores information about a file's name history in its SCCS history file. The name history is simply a list of the workspace-relative names that have been given to the file during its lifetime. This information is used by Configuring to differentiate between files that have been renamed and those that are new. When you rename a file, Configuring updates the file's name history during the next Bringover or Putback transaction that includes it. When a name history is updated, you are notified in the Transaction Output window. 

Names Summary:
			1	updated parent's name history
			1 	updated children's name history

Rename Conflicts

In rare cases, a file's name is changed concurrently in parent and child workspaces. This is referred to as a rename conflict. For example, the name of file "C" is changed to "D" in the parent, and concurrently to "E" in the child.

Figure 8-4 File "C" is Concurrently Renamed in both Parent and Child Workspaces

Graphic

When this occurs, Configuring determines that both "D" in the parent and "E" in the child are actually the same file, but with different names. In the case of rename conflicts:

When Configuring encounters a rename conflict, you are notified in the Transaction Output window with the following messages: 

rename conflict: name_in_child
rename from: name_in_child
         to: name_in_parent

Deleting Files

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.

Figure 8-5 File "C" Is Removed From The Child Using the rm Command, Then Created Again by Bringover

Graphic

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: