Avoid disrupting the work of other developers

To work productively, developers need to control when they see changes and which changes they see. The appropriate mechanism for this purpose is a view. Developers can modify an existing config spec or create a new one to specify exactly which changes to see and which to exclude.

To implement this policy, you can also require developers to write and distribute the config spec rule that filters out their checked-in changes. The following are sample config specs:
  • To select your own work, plus all the versions that went into the building of Release 2:
    element * CHECKEDOUT
    element * REL2
  • To select your own work, plus the latest versions as of Sunday evening:
    element * CHECKEDOUT
    element * /main/LATEST -time Sunday.18:00
  • To select your own work, new versions created in the graphics directory, and the versions that went into a previous build:
    element * CHECKEDOUT
    element graphics/* /main/LATEST
    element * -config myprog@@12-Jul.00:30
  • To select your own work, the versions either you (jones) or Mary has checked in today, and the most recent quality-assurance versions:
    element * CHECKEDOUT
    element * ’/main/{ created_since(06:00) && ( created_by(jones) ||
    created_by(mary) ) }’
    element * /main/{QAed=="TRUE"}
  • To use the config spec include facility to set up standard sets of configuration rules for developers to add to their own config specs:
    element * CHECKEDOUT
    element msg.c /main/18
    include /usr/cspecs/rules_for_rel2_maintenance