Provided by: aegis_4.24.3-3_amd64 bug

NAME

        aepattr - aegis project attribute file

DESCRIPTION

        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;
                File permission mode mask.  See umask(2) for more information.  This value will
                always be OR'ed with 022, because aegis is paranoid.

        default_test_exemption = boolean;
                This field contains what to do when a change is created with no test exemption
                specified.

        default_test_regression_exemption = boolean;
                This field contains what to do when a change is created with no regression test
                exemption specified.

        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.

                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.

        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.D001
        Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
        2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Peter Miller

        The aegis program comes with ABSOLUTELY NO WARRANTY; for details use the 'aegis -VERSion
        License' command.  This is free software and you are welcome to redistribute it under
        certain conditions; for details use the 'aegis -VERSion License' command.

AUTHOR

        Peter Miller   E-Mail:   millerp@canb.auug.org.au
        /\/\*             WWW:   http://www.canb.auug.org.au/~millerp/