

aepattr(5)					       aepattr(5)


NNAAMMEE
       aepattr - project attribute file

DDEESSCCRRIIPPTTIIOONN
       The project attribute file is used to store modifiable
       information about a project.

CCOONNTTEENNTTSS
       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 _d_e_v_e_l_o_p___e_n_d___a_c_t_i_o_n	field may not
	       contradict the _d_e_v_e_l_o_p_e_r___m_a_y___r_e_v_i_e_w field.  If
	       developers may not review their own work, then
	       their changes may not goto directly to the _b_e_i_n_g
	       _i_n_t_e_g_r_a_t_e_d 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 _a_e_d_b _-_U_s_e_r	command
	       to force	development of a change	by a specific
	       user.  All of the substitutions described in
	       _a_e_s_u_b(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 _a_e_s_u_b(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 _a_e_s_u_b(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 _a_e_s_u_b(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
	       _a_e_s_u_b(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 _a_e_s_u_b(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 _d_e_v_e_l_o_p___e_n_d___n_o_t_i_f_y___c_o_m_m_a_n_d field.  All of the
	       substitutions described by _a_e_s_u_b(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 _a_e_s_u_b(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 _a_e_s_u_b(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 _a_e_s_u_b(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 _u_m_a_s_k(2)	for more
	       information.  This value	will always be OR'ed with
	       022, because _a_e_g_i_s is paranoid.

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

       minimum_change_number = integer;
	       The minimum change number for _a_e_n_c_(_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
	       _a_e_n_c(1) change numbers ``fill in'' any gaps.
	       Defaults	to true	if not set.

       minimum_branch_number = integer;
	       The minimum branch number for _a_e_n_b_r_(_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
	       preformance of file-related commands.

       develop_end_action = ( ...);
	       This field controls the state the change	enters
	       after a successful _a_e_d_e(1) action.

	       _g_o_t_o___b_e_i_n_g___r_e_v_i_e_w_e_d
		       This means that the change goes from the
		       _b_e_i_n_g___d_e_v_e_l_o_p_e_d state to	the _b_e_i_n_g___-
		       _r_e_v_i_e_w_e_d	state.	The _a_e_r_b(1) command only
		       sends informative email.

	       _g_o_t_o___a_w_a_i_t_i_n_g___r_e_v_i_e_w
		       This means that the change goes from the
		       _b_e_i_n_g___d_e_v_e_l_o_p_e_d state to	the _a_w_a_i_t_i_n_g___-
		       _r_e_v_i_e_w state.  The _a_e_r_b(1) command is now
		       mandatory.


	       _g_o_t_o___a_w_a_i_t_i_n_g___i_n_t_e_g_r_a_t_i_o_n
		       This means that the change goes from the
		       _b_e_i_n_g___d_e_v_e_l_o_p_e_d state into the _a_w_a_i_t_i_n_g___-
		       _i_n_t_e_g_r_a_t_i_o_n state.  Code	review is skipped
		       entirely.  If the _d_e_v_e_l_o_p_e_r___m_a_y___r_e_v_i_e_w is
		       false, it is not	possible to use	this
		       setting.

	       Note that the _d_e_v_e_l_o_p___e_n_d___a_c_t_i_o_n	field may not
	       contradict the _d_e_v_e_l_o_p_e_r___m_a_y___r_e_v_i_e_w field.  If
	       developers may not review their own work, then
	       their changes may not goto directly to the _b_e_i_n_g
	       _i_n_t_e_g_r_a_t_e_d state	(as this means much the	same
	       thing).	A contradictory	setting	will be	replaced
	       with _g_o_t_o___b_e_i_n_g___r_e_v_i_e_w_e_d.

SSEEEE AALLSSOO
       _a_e_p_a(1) modify the attributes of	a project

       _a_e_g_i_s(5)
	       aegis file format syntax

       _a_e_c_a_t_t_r(5)
	       change attributes file format

       _a_e_c_s_t_a_t_e(5)
	       change state file format, particularly as branches
	       are used	to remember most project state

       _a_e_p_s_t_a_t_e(5)
	       project state file format

CCOOPPYYRRIIGGHHTT
       aegis version .C001
       Copyright (C) 1991, 1992, 1993, 1994, 1995, 1996, 1997,
       1998, 1999, 2000, 2001 Peter Miller; All	rights reserved.

       The aegis program comes with ABSOLUTELY NO WARRANTY; for
       details use the '_a_e_g_i_s _-_V_E_R_S_i_o_n _L_i_c_e_n_s_e'	command.  This is
       free software and you are welcome to redistribute it under
       certain conditions; for details use the '_a_e_g_i_s _-_V_E_R_S_i_o_n
       _L_i_c_e_n_s_e'	command.

AAUUTTHHOORR
       Peter Miller   E-Mail:	millerp@canb.auug.org.au
       /\/\*		 WWW:	http://www.canb.auug.org.au/~millerp/


Reference Manual	      Aegis				1