These are some thoughts on source control for immodular programs.

The Keykos kernel is devoted to providing a platform to support highly modular programs. Indeed it helps modularity to the extent that it also provides security. One result is that the kernel is itself highly immodular. There is a general pattern for removing things from the kernel but the tradeoff between performance and modularity causes a good deal of code to remain in the kernel. The Keykos kernel is currently about 100KB of machine code which is not terribly big for a modular program but cumbersome for an immodular one.

By immodular I mean that performance improvements and bug fixes are typically of the form of a small change to some structure format and then modifications in each of several files. I have often seen a change consist of one instruction in each of four or five files.

IBM’s CMS software development environment provided storage of source files in the conventional forward difference scheme. A change had a name and it was possible to remove a change even if it were not the most recent change. I think that no system can ensure that all combinations of changes will work or even compile. If the two changes do not collide, or nearly collide, in each of the files that they impact, then there is a good chance that they will be orthogonal and can be selected independently. Even when we supported just one machine in assembler, the kernel would undergo tentative changes that had to be integrated with production systems to evaluate their performance and stability. Most changes were successful but it was a great benefit that we could occasionally back out a change which was several released modifications back.

Orthogonal modifications are also a great aid in parallel development of software. I worked on a Fortran compiler involving three small development groups that were adding new function. One group fixed exigent bugs and high priority improvements while the other two worked on larger improvements that required many months. The long term improvements needed to test frequently with the most recent version of the compiler, yet the code produced by them would render the compiler unusable until it was done.