13.2 Notes on conflicts, superceding, prerequisites and parents

To a first approximation, patches are disjoint; any patch to be installed should have no files in common with any patch already installed. However, it is possible to engineer exceptions by avoiding conflicts in a number of ways:

1.

SUPERCEDE. The configuration file can specify, through the supercede stanza, that if a given patch is already applied, it is first removed. This avoids conflicts, and is intended for use when the new patch completely replaces the old patch.

2.

PREREQUISITE. The configuration file can mark a number of prerequisite patches which have to be applied before the current patch. This can sometimes enable one to break down a group of files into subsets to be applied separately, increasing the chances of avoiding conflicts with other updates.

3.

PARENTHOOD. In contrast to superceding and prerequisition, this mechanism is automatic and does not require user specification. The idea is that one or more files in a new patch have been prepared from an earlier patch, rather than the version base. The earlier 'parent' patch will have marked its presence in the RCS header of the file, and on building the new 'child' patch, the new patch identifier will also be added to the header. On applying the child patch, if the old patch is already installed, the conflict which would otherwise result is suppressed. In order for the patch reversion mechanism to work, however, it then becomes impossible for the parent patch to be removed without first removing all of its children; this is enforced strictly by the parent's revert script. Similarly, it is impossible to apply a patch which is the parent of any currently installed patch.