Chapter 10 How Configuring Merges SCCS Files
This chapter describes the ways the Configuring program manipulates SCCS history files when you copy files between workspaces and resolve conflicts.
-
Note -This discussion assumes that you are familiar with SCCS, including the concept of branching. SCCS is described in detail in the Solaris Programming Utilities manual.
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").
When a file is copied (by means of Bringover or Putback transaction) from a source workspace to a destination workspace, it appears that a single file has been transferred. In fact, all of the SCCS information for that file (deltas, comments, and so on) must be merged into the destination SCCS history file. By merging the information from the source into the destination history file, the current version (delta) can be derived, and the file's entire delta and comment history are available. (The exception is when the file does not exist in the destination workspace. In this case, the entire history file is copied from the source workspace to the destination workspace.)
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.
To accomplish the merger, the Configuring program determines where the delta histories diverge and adds (to the destination workspace) only the deltas that were created in the source workspace since they diverged. To determine where the histories diverge, the Configuring program compares the delta tables in both the parent and child history files; information used in this comparison includes comments and data such as when and who created the delta. Figure 10-1 contains an example of a Putback transaction where the Configuring program adds deltas 1.3 and 1.4 from the child workspace to the SCCS history file in the parent.
Figure 10-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.
When file contents conflict, Configuring aids you in resolving the potentially conflicting changes that were made to the file, and preserves the file's delta, administrative, and comment history. To accomplish this, Configuring merges the SCCS deltas from the parent into the history file in the child. Configuring's Resolve transaction is then used to resolve the conflict in the child. See Chapter 9, Resolving Conflicts" for details on resolving conflicts.
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.
- © 2010, Oracle Corporation and/or its affiliates