This field details the years in which the change was worked on.
This field is present in trunk, branch and leaf nodes.
As a change is edited, years in which the change was worked on
accumulate in this field automatically.
Branches accumulate years as integrations occur.
You may need to manually edit this,
though it should be rare.
This field is the absolute path of a change's development directory.
It is only present of the change is in a state
between
being_developed and
being_integrated inclusive.
However, branches are treated slightly differently to changes.
The directory is relative to the root of the project tree, in order to
facilitate moving the project without rewriting any of the database.
Note that its doesn't point to the branch baseline, but one level up;
just as the project root doesn't point to the trunk baseline, but rather
one level up.
This field is only present for branches (long transactions).
- umask = integer;
-
File permission mode mask.
See
umask(2) for more information.
This value will always be OR'ed with 022,
because
aegis is paranoid.
- 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.
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_test_exemption = boolean;
-
This field contains what to do when a change is created with
no test exemption specified.
- history = [{ ... }];
- This field contains a history of integrations for the project.
Updated by each successful '(n) -Integrate_Pass' command.
- delta_number = integer;
- The delta number of the integration.
- change_number = integer;
- The number of the change which was integrated.
- name = [ string ];
- The names by which this delta is known.
- change = [integer];
- The list of changes which have been created on this branch to date.
- sub_branch = [integer];
- The list of branches which have been created on this branch to date.
This will be a subset of the above (possibly empty, possibly complete,
never larger).
- administrator = [string];
- The list of administrators of the branch.
- developer = [string];
- The list of developers of the branch.
- reviewer = [string];
- The list of reviewers of the branch.
- integrator = [string];
- The list of integrators of the branch.
- currently_integrating_change = integer;
- The change currently being integrated.
Only one change (within a branch) may be integrated at a time.
Only set when an integration is in progress.
- 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.
- 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.
Defaults to 10 if not set, may not be less than 1.
- 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 uncompress 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.
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).
A contradictory setting will be replaced with goto_%being_%reviewed.