Provided by: aegis_4.24.3-2_i386 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/