aepattr(5) | File Formats Manual | aepattr(5) |
NAME¶
aepattr - aegis project attribute fileDESCRIPTION¶
The project attribute file is used to store modifiable information about a project.CONTENTS¶
- description = string;
- This field contains a description of the project. Large amounts of prose are not required; a single line is sufficient.
- developer_may_review = boolean;
If this field is true, then a developer may
review her own change. This is probably only a good idea for projects of less
than 3 people. The idea is for as many people as possible to critically
examine a change.
Note that the develop_end_action field may not contradict the
developer_may_review field. If developers may not review their own
work, then their changes may not goto directly to the being
integrated state (as this means much the same thing).
- developer_may_integrate = boolean;
- If this field is true, then a developer may integrate her own change. This is probably only a good idea for projects of less than 3 people. The idea is for as many people as possible to critically examine a change.
- reviewer_may_integrate = boolean;
- If this field is true, then a reviewer may integrate a change she reviewed. This is probably only a good idea for projects of less than 3 people. The idea is for as many people as possible to critically examine a change.
- developers_may_create_changes = boolean;
- This field is true if developers may created changes, in addition to administrators. This tends to be a very useful thing, since developers find most of the bugs.
- forced_develop_begin_notify_command = string;
This command is used to notify a developer
that a change requires developing; it is issued when a project administrator
uses an aedb -User command to force development of a change by a
specific user. All of the substitutions described in aesub(5) are
available. This field is optional.
Executed as: the new developer. Current directory: the development directory of
the change for the new developer. Exit status: ignored.
- develop_end_notify_command = string;
This command is used to notify that a change
is ready for review. It will probably use mail, or it could be an in-house
bulletin board. This field is optional, if not present no notification will be
given. This command could also be used to notify other management systems,
such as progress and defect tracking. All of the substitutions described by
aesub(5) are available.
Executed as: the developer. Current directory: the development directory of the
change. Exit status: ignored.
- develop_end_undo_notify_command = string;
This command is used to notify that a change
had been withdrawn from review for further development. It will probably use
mail, or it could be an in-house bulletin board. This field is optional, if
not present no notification will be given. This command could also be used to
notify other management systems, such as progress and defect tracking. All of
the substitutions described by aesub(5) are available.
Executed as: the developer. Current directory: the development directory of the
change. Exit status: ignored.
- review_begin_notify_command = string;
This command is used to notify that a review
has begun. It will probably use mail, or it could be an in-house bulletin
board. This field is optional, if not present no notification will be given.
This command could also be used to notify other management systems, such as
progress and defect tracking. All of the substitutions described by
aesub(5) are available.
Executed as: the reviewer. Current directory: the development directory of the
change. Exit status: ignored.
- review_begin_undo_notify_command = string;
This command is used to notify that a review
is no longer in progress, the reviewer has withdrawn. It will probably use
mail, or it could be an in-house bulletin board. This field is optional, if
not present no notification will be given. This command could also be used to
notify other management systems, such as progress and defect tracking. All of
the substitutions described by aesub(5) are available.
Executed as: the reviewer. Current directory: the development directory of the
change. Exit status: ignored.
- review_pass_notify_command = string;
This command is used to notify that a review
has passed. It will probably use mail, or it could be an in-house bulletin
board. This field is optional, if not present no notification will be given.
This command could also be used to notify other management systems, such as
progress and defect tracking. All of the substitutions described by
aesub(5) are available.
Executed as: the reviewer. Current directory: the development directory of the
change. Exit status: ignored.
- review_pass_undo_notify_command = string;
This command is used to notify that a review
has passed. It will probably use mail, or it could be an in-house bulletin
board. This field is optional, if not present no notification will be given.
This command could also be used to notify other management systems, such as
progress and defect tracking. Defaults to the same action as the
develop_end_notify_command field. All of the substitutions described by
aesub(5) are available.
Executed as: the reviewer. Current directory: the development directory of the
change. Exit status: ignored.
- review_fail_notify_command = string;
This command is used to notify that a review
has failed. It will probably use mail, or it could be an in-house bulletin
board. This field is optional, if not present no notification will be given.
This command could also be used to notify other management systems, such as
progress and defect tracking. All of the substitutions described by
aesub(5) are available.
Executed as: the reviewer. Current directory: the development directory of the
change. Exit status: ignored.
- integrate_pass_notify_command = string;
This command is used to notify that an
integration has passed. It will probably use mail, or it could be an in-house
bulletin board. This field is optional, if not present no notification will be
given. This command could also be used to notify other management systems,
such as progress and defect tracking. All of the substitutions described by
aesub(5) are available.
Some compilers bury absolute path names into object files and executables. The
renaming of the integration directory to become the new baseline breaks these
paths. This command is passed an environment variable called
AEGIS_INTEGRATION_DIRECTORY so that the appropriate symlink may be placed, if
desired.
Executed as: the project owner. Current directory: the new project baseline.
Exit status: ignored.
- integrate_fail_notify_command = string;
This command is used to notify that an
integration has failed. It will probably use mail, or it could be an in-house
bulletin board. This field is optional, if not present no notification will be
given. This command could also be used to notify other management systems,
such as progress and defect tracking. All of the substitutions described by
aesub(5) are available.
Executed as: the integrator. Current directory: the development directory of the
change. Exit status: ignored.
- default_development_directory = string;
- The pathname of where to place new development directories. The pathname must be absolute. This field is only consulted if the field of the same name in the user configuration file is not set.
- umask = integer;
-
- default_test_exemption = boolean;
-
- default_test_regression_exemption = boolean;
-
- minimum_change_number = integer;
- The minimum change number for aenc(1), if no change number is specified. This allows the low-numbered change numbers to be used for branches later in the project.
- reuse_change_numbers = boolean;
- This controls whether the automatically selected aenc(1) change numbers “fill in” any gaps. Defaults to true if not set.
- minimum_branch_number = integer;
- The minimum branch number for aenbr(1), if no branch number is specified. Defaults to 1 if not set.
- skip_unlucky = boolean;
- This field may be set to true if you want to skip various unlucky numbers for changes, branches and tests. Various traditions are avoided, both Eastern and Western. Defaults to false if not set.
- compress_database = boolean;
This field may be set to true if you want to
compress the database on writing. (It is always uncompressed on reading if
necessary.) Defaults to false if not set.
Unless you have an exceptionally large project, coupled with fast CPUs and high
network latency, there is probably very little benefit in using this feature.
(The database is usually less than 5% of the size of the repository.) On slow
networks, however, this can improve the performance of file-related
commands.
- develop_end_action = ( ...);
This field controls the state the change
enters after a successful aede(1) action.
- goto_being_reviewed
- This means that the change goes from the being_developed state to the being_reviewed state. The aerb(1) command only sends informative email.
- goto_awaiting_review
- This means that the change goes from the being_developed state to the awaiting_review state. The aerb(1) command is now mandatory.
- goto_awaiting_integration
- This means that the change goes from the being_developed state into the awaiting_integration state. Code review is skipped entirely. If the developer_may_review is false, it is not possible to use this setting.
- protect_development_directory = boolean;
This field may be used to protect the
development directory after the being developed state. It does this by
making it read-only at develop end time. Should the change ever be returned to
the being developed state, it will be made writable again.
The default is false, meaning to leave the development directory writable while
is being reviewed and integrated. Aegis' normal tampering detection will
notice if files are changed, but there is no reminder to the developer that
the change should be left alone.
This field defaults to false, because it can sometimes be slow.
SEE ALSO¶
- aepa(1)
- modify the attributes of a project
- aegis(5)
- aegis file format syntax
- aecattr(5)
- change attributes file format
- aecstate(5)
- change state file format, particularly as branches are used to remember most project state
- aepstate(5)
- project state file format
COPYRIGHT¶
aegis version 4.24.3.D001AUTHOR¶
Peter Miller | E-Mail: | millerp@canb.auug.org.au |
/\/\* | WWW: | http://www.canb.auug.org.au/~millerp/ |
Aegis | Reference Manual |