Previous

Next

Contents

Index

Doc Set

Home

Resolving Conflicts

9

This chapter discusses the process by which the Configuring program detects conflicts and then assists you in resolving these conflicts.


Detecting Conflicts during Bringover Update Transactions	page 116
Preparing Files for Conflict Resolution	page 117
Resolve Transaction	page 118
The Merging Program	page 119

Conflict Resolution Process

When files change concurrently in both a parent and child workspace, they are in conflict. Neither the version of the file in the child nor the version in the parent can be copied to the other without overwriting changes. Conflicts are detected during Bringover Update transactions. You must resolve conflicts in the child before the conflicting file(s) can be put back to the parent. The Configuring program assists you in resolving conflicts. Use the following procedures to resolve conflicts if you are using the GUI. If you are using the CLI, see the resolve(1) manual page for more information.

Changing Names

The current release of TeamWare uses new command names, so the following table summarizes the correspondences for you. Note that the old commands still work, however this manual uses the new commands and GUI names.

Table 9-1 Correspondences Between New and Old TeamWare Commands
Old Command	New Command	Old Tool Name	New GUI Name
codemgrtool	twconfig, teamware	CodeManager	Configuring
vertool	twversion	VersionTool	Versioning
filemerge	twmerge	FileMerge	Merging
maketool	twbuild	MakeTool	Building
freezepttool	twfreeze	FreezePoint	Freezepointing

Detecting Conflicts

Before you can resolve conflicts, the Configuring program must detect the conflict and prepare the history files of the conflicting files for resolving. These two processes are described in this section.

Detecting Conflicts during Bringover Update Transactions

Usually, the conflict resolution process begins when you attempt to put back files that have changed in both the parent and the child workspaces. The Putback transaction blocks the transfer of files from the child to the parent because the version of the file from the child will overwrite changes made in the parent.

After the Putback transaction is blocked, you must use the Bringover Update transaction to update the child. (If Putback is executed with the Auto Bringover option specified, then the Bringover transaction is initiated automatically by the Configuring program.) If, during the Bringover transaction, the Configuring program determines that the file in the child has also changed, a conflict exists. All files included in the Bringover Update transaction that are not in conflict are copied or updated normally.

Preparing Files for Conflict Resolution

When a conflict is encountered during a Bringover Update transaction, the Configuring program takes special steps to prepare that file so that you can resolve the conflict.

The Configuring program incorporates the deltas created in the parent into the SCCS history file in the child. The parent and child deltas are placed on separate branches in the child SCCS history file. After the deltas are merged, the history file in the child contains:

Delta(s) created in the parent
Delta(s) created in the child
The delta from which the two versions of the file are both descended (their common ancestor)

Note - The Versioning program enables you to view graphical depictions of SCCS delta histories (including branches).

Access to the three deltas (common ancestor, parent, and child) in the child enables you to use the Configuring Resolve transaction and the Merging program to compare the parent and child deltas -- both to their common ancestor, and to each other.

In addition to merging deltas, the Configuring program adds the name of the conflicted file to the child's Codemgr_wsdata/conflicts file. The conflicts file is a text file that contains the names of all files in that workspace with unresolved conflicts.

The stage is set for you to resolve the conflicts using the Configuring Resolve transaction.

Resolving Conflicts

The two tools that you use to resolve conflicts are:

Configuring Resolve Transactions window
Merging program

Resolve Transaction

The Resolve layout of the Transactions window facilitates resolving conflicts detected during Bringover Update transactions. The Resolve transaction coordinates the merging process, acting as intermediary between you and the file-merging program--Merging.

As previously mentioned, when the Configuring program detects a conflict during a Bringover Update transaction, it does the following:

Merges new deltas from the parent into the SCCS history in the child
Enters the file's path name in the child's Codemgr_wsdata/conflicts file

To resolve conflicts in a workspace, follow these four steps:

1. Double-click SELECT on the icon of a workspace that contains conflicted files.

The Resolve layout of the Transaction window is automatically activated with the names of its conflicted files displayed in the File List Pane.

2. Select a file in the File List Pane and then invoke the Merging selection button.

The Configuring program starts the Merging program and begins to process the list of files from the File List Pane. For the next file in the list, the Configuring program extracts the parent delta, the child delta, and the common ancestor from the SCCS history file and passes their path names to the Merging program. (Configuring and Merging communicate via the ToolTalk^TM service. The ToolTalk service is a network-spanning, interapplication communication service that allows applications to communicate with other autonomous applications.) The Merging window appears with the files loaded and ready for merging.

3. Use Merging to resolve the differences between the parent and child versions of the file.

See "The Merging Program" for more information.

4. Save the file in Merging.

After you use Merging to resolve differences between the parent and child versions of the file, the Configuring program creates a new delta in the child SCCS history file and removes the file name from the conflicts file. The new delta contains the "Merged Result" you created using Merging.

Notes about the Resolve Transaction

By default, the Configuring program automatically, sequentially processes the list of files from the File List Pane. After you resolve a conflict, the Configuring program automatically begins to process the next file in the list. If you want to change the behavior so that it individually processes only files that you explicitly select, deselect the Auto Advance check box in the Properties window.
Conflicts need not be resolved immediately. You can continue to make changes and create new deltas in conflicted files in the child workspace. New deltas are created on a branch; when you finally resolve the conflict, the latest delta is the one merged with the version brought over from the parent. Conflicts must be resolved before you can put back the files to the parent.
When the Configuring program creates the new delta in the child SCCS history file, it includes the following standard comment:
Merged changes between workspaces x and y

By default, the Configuring program does not prompt you for a comment to append to its comment. If you want to be prompted for comments that are appended to the standard comment, select the Skip Checkin Comments check box in the Properties window.

The Merging Program

This section is a brief introduction to the Merging program as used with the Configuring program. For a more detailed description, refer to the Merging section in this manual.

Merging displays two text files (the parent and child deltas) for side-by-side comparison, each in a read-only subwindow. Beneath them, Merging displays a subwindow that contains a merged version of the two files. The merged version contains selected lines from either or both deltas and can be edited to produce a final merged version.

Each delta in each of the top windows is shown in comparison to the common ancestor delta:

The child delta may be in the left window labeled "Child vs. Ancestor"
The parent delta may be in the right window labeled "Parent vs. Ancestor"

The common ancestor is the delta from which both the parent and child deltas are descended. This arrangement permits you to make a three-way comparison--each delta to the common ancestor, and each delta to the other.

Lines in each descendant are marked according to their relationship to the corresponding lines in the common ancestor:

If a line is identical in all three deltas, then no glyph appears.
If a line is not in the ancestor but was added to one or both of the descendants, then a plus sign glyph (+) appears next to the line in the delta where the line was added.
If a line is present in the ancestor but was removed from one or both of the descendants, then a minus sign (-) appears as a placeholder in the delta from which the line was removed.
If a line is in the ancestor but has been changed in one or both of the descendants, then a vertical bar glyph (|) appears next to the line in the delta where the line was changed.

When Merging discovers a line that differs between either of the two deltas and the ancestor, it marks with glyphs the lines in the two deltas and also in the automatically merged file. Together, these marked lines are called a difference. While Merging is focusing on a difference, it highlights the glyphs.

The difference on which Merging is focusing at any given time is called the current difference. The difference that appears immediately later in the file is called the next difference; the difference that appears immediately earlier in the file is called the previous difference.

While focusing on a difference, you can accept a line from either of the original deltas, or you can edit the merged version by hand. When you indicate that you are satisfied with your changes (by clicking on a control panel button), the current difference is said to be resolved. After a difference is resolved, Merging changes the glyphs that mark the difference to outline (hollow) font. Merging then automatically advances to the next difference (if the Auto Advance property is on), or moves to another difference of your choice.

In summary, when used with the Configuring program, Merging activity is coordinated by the Resolve transaction window. The Configuring and Merging programs communicate bidirectionally through the ToolTalk service. The Configuring program extracts the parent, child, and common ancestor deltas and starts the Merging program, passing it the names of the files that contain the deltas to be merged. When you complete the merge process using the Merging Save button, the Configuring program creates a new delta in the file's SCCS history file that contains the "Merged Results" and removes the file name from the conflicts file.

In the next chapter we consider how to administer the TeamWare workspaces.

Previous

Next

Contents

Index

Doc Set

Home