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:

• D has been newly created in the parent.

• It is the same file as C in the child, only with a new name.

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

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

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:

• Configuring reports the conflict using the name of the file in the child.

• Configuring always resolves the conflict by automatically changing the name of the file in the child workspace to the current (renamed) name in the parent; the name of the file from the parent is always chosen, even in the case of a Putback transaction.

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

---