An Example of Merging

This merge example involves an integration workspace and two child workspaces owned by different developers. The developers bring over copies of the same file from the integration workspace, and independently change the file. The illustrations show how the SCCS history file is manipulated when conflicts occur and when they are resolved. Some notes regarding the following figures:

• The default delta (the point at which the next delta is added to the SCCS delta tree) is identified by an unattached descending line.

• You can use Versioning to graphically display SCCS delta trees in much the same way they are depicted here.

Both developers copy the same file from the integration workspace with the Bringover transaction. The file is new in both workspaces, so the SCCS history file is copied to both.

Developer B makes changes to the file, creating two new deltas: 1.3 and 1.4, and then puts the file back into the integration workspace (with the Putback transaction). Configuring appends the two new deltas to the parent SCCS delta tree.

Rather than replacing the destination workspace version of the SCCS history file with the source's version, the new deltas are added to the destination SCCS history file to preserve administrative information, such as access lists.

In the meantime, Developer A also changes the file (creating three new deltas: 1.3, 1.4, and 1.5) and now attempts to put back the file into the integration workspace.

Configuring blocks the Putback transaction of Developer A because the files are in conflict. The changes put back by Developer B would be overwritten. Developer A must also incorporate the changes made by Developer B into his work.

Developer A brings over the file that now contains the changes made by Developer B into his workspace from the integration workspace. The deltas created by Developer B are added into the child SCCS history file by Configuring.

The delta tree brought down from the parent is unchanged in the child. The new deltas created in the child are attached as an SCCS branch to the last delta that the child and parent had in common; the deltas from the child are assigned new SIDs accordingly. The deltas are renumbered using the SCCS branch numbering algorithm that derives the SID from the point at which it branches. In this case the branch is attached to SID 1.2; the first delta is renumbered to 1.2.1.1. The last delta created in the child (1.2.1.3, formerly 1.5) is still the default delta. Therefore, any new deltas that Developer A creates in the child before the conflict is resolved are added to the child line of work, and not the trunk (the parent line of work).

Developer A resolves the conflict in his workspace using the Resolve transaction (see Chapter 9, Resolving Conflicts" for details regarding conflict resolution). Developer A uses the Resolve transaction to help him decide how to merge the versions of the file represented by SIDs 1.2.1.3 and 1.4. When he commits the changes, the Resolve transaction places the newly merged contents into a new delta 1.5:

• The new delta, 1.5, is contained in a circle because it is created by Developer A.

• The newly created delta is now the default location for any new work created by Developer A.

With the conflict resolved, Developer A puts back the file into the integration workspace. The branch and the newly created delta are added to the SCCS history file in the integration workspace.

Developer B makes another change to the file in her workspace, creating delta 1.5. She attempts to put back the new work to the integration workspace, but the Putback transaction is blocked because it conflicts with the newly merged delta 1.5 that was put back by Developer A.

Developer B brings over the changed file into her workspace where its deltas are added into the child SCCS history file and renumbered by Configuring.

As in the previous case, Configuring appends the delta created by Developer B to the last common delta on the delta tree trunk as a branch and renumbers it appropriately. 1.5 becomes 1.4.1.1. 1.4.1.1 remains the default delta. Any new deltas created in the child before the conflict is resolved will be added to the branch.

Using the Resolve transaction, Developer B resolves the conflict merging the differences between 1.5 and 1.4.1.1 to create the new delta 1.6:

• The newly created merged contents are added as a new delta to the parent delta 1.6.

• The new delta is owned by the developer who owns the workspace.

• The new delta becomes the default delta; therefore, new work in the child will now be added beneath it.