How the Configuring Program
|
11 |
 |
When considering Bringover and Putback transactions, remember that source files are derived from SCCS deltas and are identified by SCCS delta IDs (SIDs). When a file is copied by either a Putback or Bringover transaction, the Configuring program must manipulate the file's SCCS history file (also known as the "s-dot-file").
Note - This discussion assumes that you are familiar with SCCS, including the concept of branching. SCCS is described in detail in the Programming Utilities manual.
Merging Files That Do Not Conflict
If the file in the destination workspace is being updated (the file has changed in the source of a Bringover or Putback transaction and has not changed in the destination). The new deltas from the destination are added to the history file in the destination. The reason that SCCS history files are merged at all in this case, rather than the source history file being copied over the destination history file, is that administrative information (for example, flags and access lists) stored in the destination history file would be overwritten.
Figure 11-1 Updating a File in the Destination Workspace That Has Not Changed
Merging Files That Conflict
When you propagate files between parent and child workspaces, often both the version of the file from the parent and the version in your child changed since they were last updated. When that is the case, the parent and child versions of the file are in conflict.
An Example of Merging
This section illustrates the Configuring merging process. 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:
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). the Configuring program 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.
The Configuring program blocks the Putback 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 the Configuring program.
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 Configuring 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. Notes:
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 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 the Configuring program.
As in the previous case, the Configuring program 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 Configuring 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. Notes:
