The following is an alphabetical list of terms used in this document.
Person responsible for administering a project
The state a change is in immediately after creation.
The state a change is in after it has passed review and before it is integrated.
An optional state a change is in after it is developed, but before someone has chosen to review it..
The repository; where the project master source is kept.
The state a change is in when it is being worked on.
The state a change is in when it is being integrated with the baseline.
The state a change is in after it is developed.
A collection of files to be applied as a single atomic alteration of the baseline.
Each change has a unique number identifying it.
The state a change is in after it has been integrated with the baseline.
Each time the aeib command is used to start integrating a change into the baseline a unique number is assigned. This number is the delta number. This allows ascending version numbers to be generated for the baseline, independent of change numbers, which are inevitably integrated in a different order to their creation.
A program or programs external to aegis which may be given a set of rules for how to efficiently take a set of source files and process them to produce the final product.
Abbreviation of Dependency Maintenance Tool.
The command issued to take a change from the awaiting development state to the being developed state. The change will be assigned to the user who executed the command.
The command issued to take a change from the being developed state to the awaiting development state. Any files associated with the change will be removed from the development directory and their changes lost.
The command issued to take a change from the being developed state to the being reviewed state, or optionally to the awaiting reviewed state. The change must be known to build and test successfully.
The command issued to take a change from the being reviewed state back to the being developed state. The command must be executed by the original developer.
A member of staff allowed to develop changes.
Each change is given a unique development directory in which to edit files and build and test.
A program to save and restore previous versions of a file, usually by storing edits between the versions for efficiency.
The command used to take a change from the being integrated state to the completed state. The change must be known to build and test successfully.
The command used to take a change from the awaiting integration state to the being integrated state.
The command used to take a change from the being integrated state to the awaiting integration state.
The command used to take a change from the being integrated state back to the being developed state.
The process of merging the baseline with the development directory to form a new baseline. This includes building and testing the merged directory, before replacing the original baseline with the new merged version.
The directory used during integration to merge the existing baseline with a change's development directory
A staff member who performs integrations.
The command used to create new changes.
The command used to destroy changes.
The command used to take a change from the awaiting review state to the being reviewed state.
The command used to take a change from the being reviewed state back to the being developed state.
The command used to take a change from the being reviewed state to the awaiting integration state.
A person who may review
changes
and either pass or fail them (review_pass
or review_fail respectively).
Each change is in one of seven states: awaiting development being developed awaiting review being reviewed awaiting integration being integrated or completed
The event resulting in a change changing from one state to another.