Deleting Committed Changes

Replacing a Delta: sccs fix

Occasionally, a delta is checked in that contains small bugs, such as typographical errors, that need correcting but that do not require entries in the file audit trail. Or, perhaps the comment for a delta is incomplete or in error, even when the text is correct. In either case, you can make additional updates and replace the version log entry for the most recent delta using sccs fix:

$ sccs fix -r 1.2 program.c

This checks out version 1.2 of program.c. When you check the file back in, the current changes replaces delta 1.2 in the history file, and SCCS prompts for a (new) comment. You must supply an SID with -r. Also, the delta that is specified must be a leaf (most recent) delta.

Although the previously-checked-in delta 1.2 is effectively deleted, SCCS retains a record of it, marked as deleted, in the history file.

Before using sccs fix it is a good idea to make a copy of the current version.

Removing a Delta: sccs rmdel

To remove all traces of the most recent delta, you can use the rmdel subcommand. You must specify the SID using -r. In most cases, using fix is preferable to rmdel, since fix preserves a record of "deleted" delta, while rmdel does not (refer to sccs rmdel(1) for more information).

Reverting to an Earlier Version

To retrieve a writable copy of an earlier version, use get -k. This can be useful when you need to back track past several deltas.

To use an earlier delta as the basis for creating a new one:

1. Check out the file as you normally would (using sccs edit).

2. Retrieve a writable copy of an earlier "good" version (giving it a different file name) using get -k:

   sccs get -k -r sid -Goldname filename
   

   The -Goldname filename option specifies the name of the newly retrieved version.

3. Replace the current version with the older "good" version:

   mv oldname filename

4. Check the file back in.

   In some cases, it may be simpler just to exclude certain deltas. Or refer to "Branches " for information on how to use SCCS to manage divergent sets of updates to a file.

Excluding Deltas from a Retrieved Version

Suppose that the changes that were made in delta 1.3 aren't applicable to the next version, 1.4. When you retrieve the file for editing, you can use the -x option to exclude delta 1.3 from the working copy:

$ sccs edit -x1.3 program.c

When you check in delta 1.5, that delta will include the changes made in delta 1.4, but not those from delta 1.3. In fact, you can exclude a list of deltas by supplying a comma-separated list to -x, or a range of deltas, separated with a dash. For example, if you want to exclude 1.3 and 1.4, you could use:

$ sccs edit -x1.3,1.4 program.c

or

$ sccs edit -x1.3-1.4 program.c

In this example SCCS excludes the range of deltas from 1.3 to the current highest delta in release 1:

$ sccs edit -x 1.3-1 program.c

In certain cases when using -x there will be conflicts between versions; for example, it may be necessary to both include and delete a particular line. If this happens, SCCS displays a message listing the range of lines affected. Examine these lines carefully to see if the version SCCS derived is correct.

Since each delta (in the sense of "a set of changes") can be excluded at will, it is most useful to include a related set of changes within each delta.

Combining Versions: sccs comb

The comb subcommand generates a Bourne shell script that, when run, constructs a new history file in which selected deltas are combined or eliminated. This can be useful when disk space is at a premium.

In combining several deltas, the comb-generated script destroys a portion of the file's version log, including comments.

The -psid option indicates the oldest delta to preserve in the reconstruction. Another option,

-c sid-list

allows you to specify a list of deltas to include. sid-list is a comma-separated list; you can specify a range between two SIDs by separating them with a dash ('-') in the list. -p and -c are mutually exclusive. The -o option attempts to minimize the number of deltas in the reconstruction.

The -s option produces a script that compares the size of the reconstruction with that of the original. The comparison is given as a percentage of the original the reconstruction would occupy, based on the number of blocks in each.

When using comb, it is a good idea to keep a copy of the original history file on hand. While comb is intended to save disk space, it does not always work. In some cases, it is possible that the resulting history file might be larger than the original.

If no options are specified, comb preserves the minimum number of ancestors needed to preserve the changes made so far.