In a collaborative software development environment, it is important that individual developers share as much of the body of code as possible at any given point time. This maximizes that chances that new changes will be compatible with the code of others. Also, it is important that any differences in a developer's code versus some standard version be clearly identifiable. If that is the case, then understanding differences in results from two versions of a program is much easier. Both of these considerations favor an approach where an individual developer has a small set of code under his direct control (or at least as small as possible) and relies on a public version for the bulk of the code set. Once the private code is functional, it can be incorporated in the next standard version and removed from private directories.
This approach also is compatible with experimental code, code that is meant to be used once to try new ideas and then thrown away. Experimenting with code can be done by modifying and building the small fraction of the total code necessary; there is no need to build the entire code set in order to test out the change of a single line.
This note describes features of the PrimEx make scheme that facilitate a source code management practice that keeps private and/or experimental code to a minimum, while still maintaining the ability of a developer to change anything in the entire code set for his or her own purposes.