Branches

You can think of the deltas applied to anSCCS file as the nodes of a tree; the root is the initial version of the file. The root delta (node) is number `1.1' by default, and successor deltas (nodes) are named 1.2, 1.3, and so forth. As noted earlier, these first two parts of the SID are the release and level numbers. The naming of a successor to a delta proceeds by incrementing the level number. You have also seen how to check out a new release when a major change to the file is made. The new release number applies to all successor deltas as well, unless you specify a new level in a prior release.

Thus, the evolution of a particular file may be represented in the following figure:

Figure 5-1 Evolution of an SCCS File

This structure is called the trunk of the SCCS delta tree. It represents the normal sequential development of an SCCS file; changes that are part of any given delta depend upon all the preceding deltas.

However, situations can arise when it is convenient to create an alternate branch on the tree. For instance, consider a program that is in production use at version 1.3, and for which development work on release 2 is already in progress. Thus, release 2 might already have some deltas.

Assume that a user reports a problem in version 1.3 which cannot wait until release 2 to be corrected. The changes necessary to correct the problem will have to be applied as a delta to version 1.3. This requires the creation of a new version, but one that is independent of the work being done for release 2. The new delta thus occupies a node on a new branch of the tree.

The SID for a branch delta consists of four parts: the release and level numbers, and the branch and sequence numbers:

release.level.branch.sequence

The branch number is assigned to each branch that is a descendant of a particular trunk delta; the first such branch is 1, the next one 2, and so on. The sequence number is assigned, in order, to each delta on a particular branch. Thus, 1.3.1.1 identifies the first delta of the first branch derived from delta 1.3, as shown in the following figure.

Figure 5-2 Tree Structure with Branch Deltas

The concept of branching might be extended to any delta in the tree; the naming of the resulting deltas proceeds in the manner just illustrated. The first two components of the name of a branch delta are always those of the ancestral trunk delta.

The branch component is assigned in the order of creation on the branch, independent of its location relative to the trunk. Thus, a branch delta can always be identified as such from its name, and while the trunk delta can be identified from the branch delta name, it is not possible to determine the entire path leading from the trunk delta to the branch delta.

For example, if delta 1.3 has one branch emanating from it, all deltas on that branch will be named 1.3.1.n. If a delta on this branch then has another branch emanating from it, all deltas on the new branch will be named 1.3.2.n.

The only information that may be derived from the name of delta 1.3.2.2 is that it is the second chronological delta on the second chronological branch whose trunk ancestor is delta 1.3.

In particular, it is not possible to determine from the name of delta 1.3.2.2 all of the deltas between it and its trunk ancestor (1.3).

Figure 5-3 Extending the Branching Concept

Branch deltas allow the generation of arbitrarily complex tree structures. It is best to keep the use of branches to a minimum.

Using Branches

You can use branches when you need to keep track of an alternate version developed in parallel, such as for bug fixes or experimental purposes. Before you can create a branch, however, you must enable the "branch" flag in the history file using the sccs admin command, as follows:

$ sccs admin -f b program.c

The -fb option sets the b (branch) flag in the history file.

Creating a Branch Delta

To create a branch from delta 1.3 for program.c, you would use the sccs edit subcommand shown in the following figure:

$ sccs edit -r 1.3 -b program.c

When you check in your edited version, the branch delta contains SID 1.3.1.1. Subsequent deltas made from this branch are numbered 1.3.1.2, and so on.

Retrieving Versions from Branch Deltas

Branch deltas usually are not included in the version retrieved by get. To retrieve a branch version (the version associated with a branch delta), you must specifically request it with the -r option. If you omit the sequence number, as in the next example, SCCS retrieves the highest delta in the branch:

$ sccs get -r 1.3.1 program.c
1.3.1.1
87

Merging a Branch Back into the Main Trunk

At some point, perhaps when you've finished with the experiment, you might want to introduce the experimental features into production. But in the meantime, work may have progressed on the production version, in which case there may be incompatibilities between the branch version and the latest trunk version.

To help you sort this situation out, the -i option to sccs edit allows you to specify a list of deltas to include when you check out the file. If any of the changes that were included result in conflicts, edit issues a warning message. A conflict can arise if a line must be deleted to satisfy one delta, but inserted to satisfy another. While it is up to you to resolve each conflict, knowing where they are is a big help.