aepattr(5)		      File Formats Manual		    aepattr(5)


NNAAMMEE
	aepattr	- aegis	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 suffi-
		cient.

	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 possi-
		ble 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 possi-
		ble 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 pos-
		sible to critically examine a change.

	developers_may_create_changes =	boolean;
		This field is true if developers may created changes, in addi-
		tion 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	devel-
		opment 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 develop-
		ment directory of the change.  Exit status: ignored.

	develop_end_undo_notify_command	= string;
		This command is	used to	notify that a change had been with-
		drawn 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	man-
		agement	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 develop-
		ment 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 track-
		ing.  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 track-
		ing.  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 track-
		ing.  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 track-
		ing.  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 track-
		ing.  All of the substitutions described by _a_e_s_u_b(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 track-
		ing.  All of the substitutions described by _a_e_s_u_b(5) are
		available.

		Executed as: the integrator.  Current directory: the develop-
		ment 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.

	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 _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 tra-
		ditions	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	usu-
		ally 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	suc-
		cessful	_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.

	protect_development_directory =	boolean;
		This field may be used to protect the development directory
		after the _b_e_i_n_g	_d_e_v_e_l_o_p_e_d state.  It does this by making it
		read-only at develop end time.	Should the change ever be
		returned to the	_b_e_i_n_g _d_e_v_e_l_o_p_e_d	state, it will be made
		writable again.

		The default is false, meaning to leave the development direc-
		tory 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.

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

	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:	 pmiller@opensource.org.au
	/\/\*		  WWW:	 http://miller.emu.id.au/pmiller/


Reference Manual		     Aegis			    aepattr(5)