Obliterating Revisions

Obliterating the middle revisions as opposed to the head revision

PROBLEM

Shouldn't all of an obliterated revision's data disappear from the RCS file?  Examining the pre and post obliterate versioned (",v") files, the only thing that changes is part of the header.  The actual file content remains.

SOLUTION

This typically happens when deleting revisions from the "middle" of a revision range. For example, if a user did the following:

1. Add a file of type "text" to the depot.
2. Edit the file twice to have 3 revisions. 
3. Obliterate #2.

Perforce's RCS "delete" operation first marks revisions as deleted, and then only actually removes revisions so marked if they are at the tail end of the delta list (the first numerically).   If you delete a revision that's in the middle of a file's revisions, it just marks it as deleted and doesn't save space.

This is because deleting a middle revision would force Perforce to recompute the delta for the revision below it, which means checking out the revision to be deleted and doing a diff to determine where the obliterated delta should be stored.  That's an expensive operation that could significantly delay the completion of the "obliterate" command.

The potential space savings resulting from deleting a middle revision is usually marginal, unless you're checking in files which are very large and have many differences between revisions, in which case you would be better served saving your text files as type "ctext". See the section on " Defining filetypes with p4 typemap" in the Perforce System Administrator's Guide for more information on file types and how to change them.