

aepconf(5)					       aepconf(5)


NNAAMMEE
       aepconf - aegis project configuration file

SSYYNNOOPPSSIISS
       _p_r_o_j_e_c_t/baseline/config

DDEESSCCRRIIPPTTIIOONN
       A project configuration file is used to store information
       about a project.	 This file is under source control, and
       is one of the project's source files.  Developers may thus
       modify this file	as part	of a change.

       This file contains a number of commands to be executed by
       Aegis.  There are times when the	substitutions in these
       commands	may contain shell special characters, which would
       change the meaning of the commands in unintended	ways.
       There are two main sources of these problems: filenames
       and architecture	names.	In order to have shell special
       characters in filenames,	you must set the _s_h_e_l_l___s_a_f_e___-
       _f_i_l_e_n_a_m_e_s field (see below) to _f_a_l_s_e.  If you do	this, you
       will need to use	the quote substitution (see _a_e_s_u_b(5)) to
       quote them, so that the shell does not abuse them.  Other
       things which may	need quoting include architecture names
       if you get creative, and	edit numbers if	unusual	ones are
       generated by your history tool.

CCOONNTTEENNTTSS
       This file contains the following	fields:

       build_command = string;
	       This field describes how	to build the project
	       (actually, how to do an integration build).  This
	       field is	mandatory.  Used by the	_a_e_b(1) command.
	       All of the substitutions	described by _a_e_s_u_b(5) are
	       available.

	       Executed	as: the	intgerator (for	integration
	       builds) or the developer	(for development builds).
	       Current directory: the integration directory of
	       the change (for integration builds) the
	       development directory of	the change (for
	       development builds).  Exit status: zero is
	       considered succes, non-zero is a	failure	and a
	       subsequent successful (exit zero) build will be
	       required.

       development_build_command = string;
	       This field describes how	to do a	development
	       build.  If this field is	absent,	it defaults to
	       the above.  Used	by the _a_e_b(1) command.	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: zero is considered success, non-zero is a
	       failure and a subsequent	successful (exit zero)
	       build will be required.


       build_time_adjust_notify_command	= string;
	       This command is run when	Aegis adjusts the last-
	       time-modified time-stamp	on files in the
	       integration directory.  If the build tool uses
	       additional information to supplement file
	       modification times, this	command	gives you the
	       opportunity to re-sync the associated database.

	       Executed	as: the	project	owner.	Current
	       directory: the project baseline.	 Exit status:
	       ignored.

       build_covers_all_architectures =	boolean;
	       This field is set to true if the	build command,
	       when executed on	any architecture, results in all
	       architectures being built.  This	may be
	       accomplished, for example, by using cross-
	       compilation techiniques,	or Cook's ability to
	       nominate	hosts on which to execute each build
	       rule.

       create_symlinks_before_build = boolean;
	       This flag is true if Aegis should create	symlinks
	       from the	development directory to the baseline for
	       all files in the	baseline not in	the development
	       directory immediately before a
	       development_build_command is issued.  Usually used
	       to trick	dumb DMTs into believing the development
	       directory contains an entire copy of the	project,
	       though sometimes	the DMT	is smart enough, the
	       tools it	must work with are not.	 Symlinks in the
	       development directory which point to nonexistent
	       files will be removed.

	       Defaults	to false if not	set.

       create_symlinks_before_integration_build	= boolean;
	       This flag is true if Aegis should create	symlinks
	       from the	integration directory to the ancestral
	       baseline	for all	files in the ancestral not in the
	       integration directory immediately before	a
	       build_command is	issued.	 Usually used to trick
	       dumb DMTs into believing	the integration	directory
	       contains	an entire copy of the project, though
	       sometimes the DMT is smart enough, the tools it
	       must work with are not.	Symlinks in the
	       integration directory which point to nonexistent
	       files will be removed.

	       Defaults	to the same value as _c_r_e_a_t_e___s_y_m_l_i_n_k_s___-
	       _b_e_f_o_r_e___b_u_i_l_d if not set.

       remove_symlinks_after_build = boolean;
	       This flag is true if Aegis should remove	symlinks
	       which point from	the development	directory to the
	       baseline	directory immediately after a
	       development_build_command is issued.  Only
	       consulted if the	_c_r_e_a_t_e___s_y_m_l_i_n_k_s___b_e_f_o_r_e___b_u_i_l_d
	       field is	true, for the purpose of reversing the
	       actions of the _c_r_e_a_t_e___s_y_m_l_i_n_k_s___b_e_f_o_r_e___b_u_i_l_d field.

	       Defaults	to false if not	set.

       remove_symlinks_after_integration_build = boolean;
	       This flag is true if Aegis should remove	symlinks
	       which point from	the integration	directory to the
	       ancestral baseline directory immediately	after a
	       build_command is	issued.	 Only consulted	if the
	       _c_r_e_a_t_e___s_y_m_l_i_n_k_s___b_e_f_o_r_e___i_n_t_e_g_r_a_t_i_o_n___b_u_i_l_d	field is
	       true, for the purpose of	reversing the actions of
	       the _c_r_e_a_t_e___s_y_m_l_i_n_k_s___b_e_f_o_r_e___i_n_t_e_g_r_a_t_i_o_n___b_u_i_l_d
	       field.

	       Defaults	to ttrruuee	if not set.  This default is
	       intentional.  It	is important that there	are no
	       symlinks	in the (new) baseline, because they could
	       go stale	between	integrations.  If you set this
	       field to	false, _c_a_v_e_a_t _e_m_p_t_o_r.

       symlink_exceptions = [ string ];
	       This field is used to list filename patterns for
	       which symbolic links must not be	made between the
	       development directory and the baseline.	These are
	       usually state files for various tools.  The
	       patterns	are matched against the	whole filename;
	       naming only the last filename path element will
	       _n_o_t work	(unless	the pattern starts with	``*'').

       change_file_command = string;
	       This field contains a command to	be executed
	       whenever	a or command is	successful.  If	this
	       field is	absent,	nothing	is done.  Used by the
	       _a_e_c_p(1),	_a_e_n_v(1), _a_e_n_f(1), _a_e_r_m(1), and _a_e_m_v(1)
	       commands.  All of the substitutions described by
	       _a_e_s_u_b(5)	are available; in addition,

	       ${File_List}
		       Space separated list of files named.

	       Executed	as: the	developer.  Current directory:
	       the development directory of the	change.	 Exit
	       status: ignored.

       change_file_undo_command	= string;
	       This field contains a command to	be executed
	       whenever	a or command is	successful.  Default to
	       _c_h_a_n_g_e___f_i_l_e___c_o_m_m_a_n_d if absent.  If both fields are
	       absent, nothing is done.	 Used by the _a_e_c_p_u(1),
	       _a_e_m_v_u(1), _a_e_n_f_u(1), _a_e_n_t_u(1) or _a_e_r_m_u(1),
	       commands.  All of the substitutions described by
	       _a_e_s_u_b(5)	are available; in addition,

	       ${File_List}
		       Space separated list of files named.

	       Executed	as: the	developer.  Current directory:
	       the development directory of the	change.	 Exit
	       status: ignored.

       project_file_command = string;
	       This field contains a command to	be executed
	       during a	development build before the _d_e_v_e_l_o_p_m_e_n_t
	       _b_u_i_l_d _c_o_m_m_a_n_d above, when (a) it	is the first
	       build after a develop begin, or (b) some	other
	       change has been integrated into the baseline since
	       the last	build.	If this	field is absent, nothing
	       is done.	 Used by the _a_e_b(1) command.  All of the
	       substitutions described by _a_e_s_u_b(5) are available.

	       develop_begin_command = string;
		       This field contains a command to	be
		       executed	whenever a 'aegis -Develop_Begin'
		       command is successful.  If this field is
		       absent, nothing is done.	 Used by the
		       _a_e_d_b(1) command.	 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.

			      integrate_begin_command =	string;
		      This field contains a command to be
		      executed whenever	a 'aegis
		      -Integrate_Begin'	command	is successful.
		      If this field is absent, nothing is done.
		      Used by the _a_e_i_b(1) command.  All	of the
		      substitutions described by _a_e_s_u_b(5) are
		      available.

	       Executed	as: the	project	owner.	Current
	       directory: the integration directory.  Exit
	       status: ignored.

       link_integration_directory = boolean;
	       This flag is true if Aegis should link the files
	       from the	baseline into the integration directory,
	       rather than copy	them (the default).  This has
	       risks, as the build script (e.g.	 _H_o_w_t_o_._c_o_o_k or
	       _M_a_k_e_f_i_l_e, etc) must unlink targets before
	       rebuilding them;	if this	is not done the	baseline
	       will be corrupted.  Used	by the _a_e_i_b(1) command.

       integrate_begin_exceptions = [ string ];
	       This field may be used to specify a list	of file
	       names (and file name patterns) which are	to be
	       omitted from the	copy (link) of the baseline when
	       creating	the integration	directory.  Used by the
	       _a_e_i_b(1) command.	 This field only applies to
	       derived files, it does _n_o_t apply	to source files.
	       The patterns are	matched	against	the whole
	       filename; naming	only the last filename path
	       element will _n_o_t	work (unless the pattern starts
	       with ``*'').

       history_create_command =	string;
	       This field is used to create a new history.  The
	       command is always executed as the project owner.
	       Used by the _a_e_i_p_a_s_s(1) command.

	       It is strongly recommended that the _h_i_s_t_o_r_y___-
	       _c_r_e_a_t_e___c_o_m_m_a_n_d and _h_i_s_t_o_r_y___p_u_t___c_o_m_m_a_n_d fields are
	       identical.  If not set, the _h_i_s_t_o_r_y___c_r_e_a_t_e___c_o_m_m_a_n_d
	       field defaults to the same value	as the _h_i_s_t_o_r_y___-
	       _p_u_t___c_o_m_m_a_n_d field.

	       All of the substitutions	described by _a_e_s_u_b(5) are
	       available; in addition,

	       ${Input}
		       Absolute	path of	the source file.

	       ${History}
		       Absolute	path of	the history file.  This
		       may need	to be reworked with the	_D_i_r_n_a_m_e
		       and _B_a_s_e_n_a_m_e substitutions to yield a
		       string suitable for the history tool in
		       question.

	       See also	the _h_i_s_t_o_r_y___p_u_t___t_r_a_s_h_e_s___f_i_l_e field,
	       below.

	       Executed	as: the	project	owner.	Current
	       directory: the base of the history tree.	 Exit
	       status: zero indicates succes, all non-zero exits
	       indicate	failure	(the integrate pass will fail).

       history_get_command = string;
	       This field is used to get a file	from history.
	       The command may be executed by developers.  Used
	       by the _a_e_i_p_a_s_s(1) and _a_e_c_p(1) commands.	All of
	       the substitutions described by _a_e_s_u_b(5) are
	       available; in addition,

	       ${History}
		       The absolute path of the	history	file.
		       This may	need to	be reworked with the
		       _D_i_r_n_a_m_e and _B_a_s_e_n_a_m_e substitutions to
		       yield a string suitable for the history
		       tool in question.

	       ${Edit}
		       The edit	number to be extracted.	 It may
		       be an arbitrary string, varying on the
		       particular history tool.

	       ${Output}
		       The absolute path of the	destination file.

	       Executed	as: the	developer (or the executing user,
	       in the case of the -independent option).	 Current
	       directory: the base of the history tree Exit
	       status: zero indicates succes, all non-zero exits
	       indicate	failure	(the _a_e_c_p will fail).

       history_put_command = string;
	       This field is used to add a new change to the
	       history.	 The command is	always executed	as the
	       project owner.  Used by the _a_e_i_p_a_s_s(1) command.

	       It is strongly recommended that the _h_i_s_t_o_r_y___p_u_t___-
	       _c_o_m_m_a_n_d and _h_i_s_t_o_r_y___c_r_e_a_t_e_____c_o_m_m_a_n_d fields are
	       identical.  If not set, the _h_i_s_t_o_r_y___p_u_t___c_o_m_m_a_n_d
	       field defaults to the same value	as the _h_i_s_t_o_r_y___-
	       _c_r_e_a_t_e___c_o_m_m_a_n_d field.

	       All of the substitutions	described by _a_e_s_u_b(5) are
	       available; in addition,

	       ${Input}
		       The absolute path of the	source file.

	       ${History}
		       The absolute path of the	history	file.
		       This may	need to	be reworked with the
		       _D_i_r_n_a_m_e and _B_a_s_e_n_a_m_e substitutions to
		       yield a string suitable for the history
		       tool in question.

	       See also	the _h_i_s_t_o_r_y___p_u_t___t_r_a_s_h_e_s___f_i_l_e field,
	       below.

	       Executed	as: the	project	owner.	Current
	       directory: the base of the history tree.	 Exit
	       status: zero indicates succes, all non-zero exits
	       indicate	failure	(the integrate pass will fail).

       history_query_command = string;
	       This field is used to query the topmost edit of a
	       history file.  Result to	be printed on the
	       standard	output.	 This command may be executed by
	       developers.  Used by the	_a_e_i_p_a_s_s(1) and _a_e_c_p(1)
	       commands.  All of the substitutions described by
	       _a_e_s_u_b(5)	are available; in addition,

	       ${History}
		       The absolute path of the	history	file.
		       This may	need to	be reworked with the
		       _D_i_r_n_a_m_e and _B_a_s_e_n_a_m_e substitutions to
		       yield a string suitable for the history
		       tool in question.

	       Executed	as: the	project	owner.	Current
	       directory: the base of the history tree.	 Exit
	       status: zero indicates succes, all non-zero exits
	       indicate	failure	(the integrate pass will fail).

       history_put_trashes_file	= (fatal, warn,	ignore);
	       Many history tools (e.g.	RCS) can modify	the
	       contents	of the file when it is committed.  While
	       there are usually options to turn this off, they
	       are seldom used.	 The problem is: if the	commit
	       changes the file, the source in the repository now
	       no longer matches the object file in the
	       repository - i.e. the history tool has compromised
	       the referential integrity of the	repository.

	       fatal
		   Emit	a fatal	error if one or	more source files
		   are modified	by a _h_i_s_t_o_r_y___p_u_t___c_o_m_m_a_n_d or
		   _h_i_s_t_o_r_y___c_r_e_a_t_e___c_o_m_m_a_n_d.  This is the	default.

	       warn
		   Emit	a warning if a source file is modified.

	       ignore
		   Ignore a source file	changing.  You sure
		   better hope it was only in a	comment!

       history_content_limitation = (ascii_text,
       international_text, binary_capable);
	       This field describes the	content	style which the
	       history tool is capable of working with.

	       ascii_text
		       The history tool	can only cope with files
		       which contain printable ASCII characters,
		       plus space, tab and newline.	The file
		       must end	with a newline.	 This is the
		       default.

	       international_text
		       The history tool	can only cope with files
		       which do	not contain the	NUL character.
		       The file	must end with a	newline.

	       binary_capable
		       The history tool	can cope with all files
		       without any limitation on the form of the
		       contents.

	       When a file is added to the history (by either the
	       _h_i_s_t_o_r_y___c_r_e_a_t_e___c_o_m_m_a_n_d or the _h_i_s_t_o_r_y___p_u_t___c_o_m_m_a_n_d
	       field) it is examined for conformance to	this
	       limitation.  If there is	a problem, the file is
	       encoded in either quoted	printable for MIME64,
	       whichever is smaller, before being given	to the
	       history tool.  This encoding is transparent, the
	       file in the baseline is unchanged.

	       On extract (the _h_i_s_t_o_r_y___g_e_t___c_o_m_m_a_n_d field) the
	       encoding	is reversed, using information attached
	       to the change file information.	This is	because
	       each put	could use a different encoding (although
	       in practice, file contents rarely change	that
	       dramatically, and the same encoding is likely to
	       be deduced every	time).

       diff_command = string;
	       This field is used to difference	of 2 files.  The
	       command is always executed by developers.  Used by
	       the _a_e_d(1) command.  All	of the substitutions
	       described by _a_e_s_u_b(5) are available; in addition,

	       ${ORiginal}
		       The absolute path of the	original file
		       copied into the change.	Usually	in the
		       baseline, but not always.

	       ${Input}
		       The absolute path of the	file in	the
		       development directory.

	       ${Output}
		       The absolute path of the	file in	which to
		       write the difference listing.

	       Executed	as: the	project	owner (for integration
	       diffs), or the developer	(for development diffs).
	       Current directory: the integration directory (for
	       integration diffs), or the development directory
	       (for development	diffs).	 Exit status: zero
	       indicates succes, all non-zero exits indicate
	       failure (the aed	will fail).

       merge_command = string;
	       This field is used to merge two competing edits to
	       a file.	The command is always executed by
	       developers.  The	current	directory will be the
	       development directory.  This field is used by the
	       _a_e_d(1) command.	All of the substitutions
	       described by _a_e_s_u_b(5) are available; in addition,

	       ${ORiginal}
		       The absolute path of the	original file
		       copied into the change.	Usually	not in
		       the baseline, often a temporary file.

	       ${Most_Recent}
		       The absolute path of the	competing edit,
		       usually in the baseline.

	       ${Input}
		       The absolute path of the	file in	the
		       development directory.  This is the
		       ``preferred'' edit, if the tool has this
		       concept when highlighting conflicting
		       edits.

	       ${Output}
		       The absolute path of the	file in	which to
		       write the merged	result.	 This will
		       usually be the name if a	change source
		       file in the development directory.

	       It is important that this command does not move
	       files around.  (See the obsolete	_d_i_f_f_3___c_o_m_m_a_n_d
	       field, below, for some history.)

	       Executed	as: the	project	owner (for integration
	       diffs), or the developer	(for development diffs).
	       Current directory: the integration directory (for
	       integration diffs), or the development directory
	       (for development	diffs).	 Exit status: zero
	       indicates succes, all non-zero exits indicate
	       failure (the aed	will fail).

       patch_diff_command = string;
	       The difference of 2 files, to send around as a
	       patch.  (This isn't the same as diff_command,
	       because it's aimed at GNU Patch,	not at humans.)
	       The command is always executed by developers.
	       Used by the _a_e_p_a_t_c_h(1) command.

	       Defaults	to "set	+e; diff -c $original $input >
	       $output;	text $?	-le 1" if not set.

	       All of the substitutions	described by _a_e_s_u_b(5) are
	       available; in addition,

	       ${ORiginal}
		       The absolute path of the	original file
		       copied into the change.	Usually	in the
		       baseline, but not always.

	       ${Input}
		       The absolute path of the	file in	the
		       development directory.

	       ${Output}
		       The absolute path of the	file in	which to
		       write the difference listing.

	       Executed	as: the	project	owner (for integration
	       diffs), or the developer	(for development diffs).
	       Current directory: the integration directory (for
	       integration diffs), or the development directory
	       (for development	diffs).	 Exit status: zero
	       indicates succes, all non-zero exits indicate
	       failure (the aed	will fail).

       test_command = string;
	       This field is used to set the command to	be
	       executed	by the _a_e_t(1) command.	Defaults to
	       "$shell $file_name" if not set.

	       All of the substitutions	described in _a_e_s_u_b(5) are
	       available.  In addition:

	       ${File_Name}
		       The absolute path of the	test to	be
		       executed.

	       ${Search_Path}
		       Colon separated list of directories to
		       search for tests	and test support files.
		       (This is	a normal _a_e_s_u_b(5) substitution.)

	       ${Search_Path_Executable}
		       Colon separated list of directories to
		       search for executable files and executable
		       support files.  Usually it is the same as
		       the above, _e_x_c_e_p_t during	an ``aet -bl''
		       command.

	       Note that tests are source files, and thus never
	       have the	execute	bit set.

	       Executed	as: the	project	owner (for integration
	       tests) or the developer (for development	tests),
	       or the executing	user (for -independent tests).
	       Current directory: the integration directory (for
	       integration tests), the development directory (for
	       development tests), the project baseline	(for -bl
	       tests), or the current directory	(for
	       -indenpendent tests).  Exit status: zero	indicates
	       succes, one indicates failure, anything else
	       indicates "no result".

       development_test_command	= string;
	       This field is used to set the command to	be
	       executed	by the _a_e_t(1) command when a change is in
	       the _b_e_i_n_g _d_e_v_e_l_o_p_e_d state.  Defaults to be the
	       same as the _t_e_s_t___c_o_m_m_a_n_d	field if not set.

	       NNoottee:: It	is a significantly bad idea to make tests
	       behave differently in _b_e_i_n_g _d_e_v_e_l_o_p_m_e_n_t and _b_e_i_n_g
	       _i_n_t_e_g_r_a_t_e_d states; avoid	this at	all costs.

	       All of the substitutions	described in _a_e_s_u_b(5) are
	       available.  In addition:

	       ${File_Name}
		       The absolute path of the	test to	be
		       executed.

	       ${File_Name}
		       The absolute path of the	test to	be
		       executed.

	       ${Search_Path}
		       Colon separated list of directories to
		       search for tests	and test support files.
		       (This is	a normal _a_e_s_u_b(5) substitution.)

	       ${Search_Path_Executable}
		       Colon separated list of directories to
		       search for executable files and executable
		       support files.  Usually it is the same as
		       the above, _e_x_c_e_p_t during	an ``aet -bl''
		       command.

	       Note that tests are source files, and thus never
	       have the	execute	bit set.

	       Executed	as: the	developer.  Current directory:
	       the development directory (for development tests),
	       the project baseline (for -bl tests).  Exit
	       status: zero indicates succes, one indicates
	       failure,	anything else indicates	"no result".

       batch_test_command = string;
	       This field is used to set the command to	be
	       executed	by the _a_e_t(1) command, in preference to
	       the _t_e_s_t___c_o_m_m_a_n_d	or _d_e_v_e_l_o_p_m_e_n_t___t_e_s_t___c_o_m_m_a_n_d, if
	       set.  It	is capable of running more than	one test
	       at once.

	       All of the substitutions	described in _a_e_s_u_b(5) are
	       available.  In addition:

	       ${Output}
		      This is the name of the file to be
		      generated	to hold	the test results.  See
		      _a_e_t_e_s_t(5)	for the	format of this file.
		      A	space separated	list of	absolute paths of
		      the tests	to be executed.

	       ${File_Names}
		      The absolute path	of the tests to	be
		      executed.

	       ${File_Name}
		       The absolute path of the	test to	be
		       executed.

	       ${Search_Path}
		       Colon separated list of directories to
		       search for tests	and test support files.
		       (This is	a normal _a_e_s_u_b(5) substitution.)

	       ${Search_Path_Executable}
		       Colon separated list of directories to
		       search for executable files and executable
		       support files.  Usually it is the same as
		       the above, _e_x_c_e_p_t during	an ``aet -bl''
		       command.

	       Note that tests are source files, and thus never
	       have the	execute	bit set.

	       It is strongly recommended that you design your
	       test scripts so that they may be	executed by
	       either batch or non-batch methods.  This	permits
	       simple migration	when your environment changes.

	       Executed	as: the	project	owner (for integration
	       tests) or the developer (for development	tests),
	       or the executing	user (for -independent tests).
	       Current directory: the integration directory (for
	       integration tests), the development directory (for
	       development tests), the project baseline	(for -bl
	       tests), or the current directory	(for
	       -indenpendent tests).  Exit status: zero	indicates
	       succes, one indicates failure, anything else
	       indicates "no result".

       architecture = [{ ... }];
	       This field is a list of system and machine
	       architectures on	which each change must
	       successfully build and test.  The structures
	       listed have fields as follows:


	       name = string;
		       The name	of the architecture.  This name
		       is available in the _$_{_A_R_C_H_i_t_e_c_t_u_r_e_}
		       substitution (see _a_e_s_u_b(5) for more
		       information), as	well as	being used
		       internally by Aegis.  You may use almost
		       any name	for your architecture, but it is
		       best to avoid shell special characters and
		       white space, because it may be substituted
		       into commands to	be executed by Aegis.

	       pattern = string;
		       The system and machine architecture are
		       determined by using the _u_n_a_m_e(2)	system
		       call.  The _u_n_a_m_e(2) return value	is
		       assembled into a	string of the form
		       "_s_y_s_n_a_m_e--_r_e_l_e_a_s_e--_v_e_r_s_i_o_n--_m_a_c_h_i_n_e".

		       The pattern field must match this uname
		       result string.  The first match found is
		       used.  The pattern is a shell file name
		       pattern,	see _s_h(1) for more information.

		       For example, the	pattern
		       _S_u_n_O_S_-_4_._1_*_-_*_-_s_u_n_4_* matches a machine the
		       author commonly uses, which returns
		       _S_u_n_O_S_-_4_._1_._3_-_8_-_s_u_n_4_m from	the _u_n_a_m_e(2)
		       system call.

	       mode = (required, optional, forbidden);
		       The _m_o_d_e	field is used to control how the
		       architecture information	is used.

		       required
			       Architectures of	thus mode will be
			       copied into changes as their
			       required	architectures when the
			       change is created.  This	is the
			       default.

		       optional
			       Architectures of	thus mode will
			       _n_o_t be copied into changes as
			       their required architectures when
			       the change is created.  However,
			       if you add them subsequently, they
			       become required _f_o_r _t_h_a_t	_c_h_a_n_g_e.

		       forbidden
			       Aegis will refuse to build or test
			       on architectures	of this	mode.

		       When a change is	created, the _r_e_q_u_i_r_e_d
		       architecture names are copied into the
		       change's	architecture list.  Once names
		       are in this list, they are required for
		       the change, and the project attributes are
		       less relevant.

	       If the architecture field is not	set, it	defaults
	       to
		      architecture =
		      [
			   {
				name = "unspecified";
				pattern	= "*";
				mode = required;
			   }
		      ];

       file_template = [ { ... } ];
	       The file	template is consulted whenever a new file
	       is created, by one of the _a_e_n_f(1) or _a_e_n_t(1)
	       commands.  Each list item has the form:

	       pattern = [ string ];
		       The name	of the file, relative to the
		       development directory.  Each string is a
		       shell file name pattern;	see _s_h(1) for
		       more information.  The patterns are
		       matched against the whole filename; naming
		       only the	last filename path element will
		       _n_o_t work	(unless	the pattern starts with
		       ``*'').

	       body_command = string;
		       Command to run to initialize the	body of
		       the file.
		       Executed	as: the	developer.  Current
		       directory: the development directory of
		       the change.  Exit status: ignored.

	       body = string;
		       What to initialize the body of the file
		       to.

	       All of the substitutions	described in _a_e_s_u_b(5) are
	       available for the _b_o_d_y and _b_o_d_y___c_o_m_m_a_n_d strings.
	       (Only specify one of them.)  In addition:

	       ${File_Name}
		       will be replaced	by the name of the new
		       file.

       whiteout_template = [ { ... } ];
	       The file	template is consulted whenever a file is
	       removed,	by one of the _a_e_r_m(1) or _a_e_m_v(1)
	       commands.  It is	used to	place a	``whiteout''
	       entry in	the development	directory, in order to
	       induce compile errors of	the removed file is
	       referenced during the build.  Each list item has
	       the form:

	       pattern = [ string ];
		       The name	of the file, relative to the
		       development directory.  Each string is a
		       shell file name pattern;	see _s_h(1) for
		       more information.  The patterns are
		       matched against the whole filename; naming
		       only the	last filename path element will
		       _n_o_t work	(unless	the pattern starts with
		       ``*'').

	       body = string;
		       What to initialize the body of the file
		       to.  If not present, no whiteout	file will
		       be created; if the empty	string,	a zero-
		       length whiteout file will be created.

	       All of the substitutions	described in _a_e_s_u_b(5) are
	       available for the body string.  In addition:

	       ${File_Name}
		       will be replaced	by the name of the
		       removed file.

	       If the name of the file being removed does not
	       match any of the	filename patterns, a file
	       consisting of 1KB of very ugly garbage will be
	       generated.  The idea is that it will produce a
	       syntax error for	most languages if you try to run
	       it, compile it, or include it.

       maximum_filename_length = integer;
	       This field is used to limit the length of
	       filenames.  All new files may not have path
	       components longer than this.  Existing files are
	       not affected.  The last component must also allow
	       for the ",D" suffix of difference files.	 Where
	       this value is larger than the file system allows,
	       the file	system limit will be imposed.  Defaults
	       to 255 if not set.  Legal values	range from 9 to
	       255.

	       The file	name lengths of	project	files will be
	       checked at develop end if the project _c_o_n_f_i_g file
	       is in the change.  See _a_e_d_e _(_1_) for more
	       information.

       posix_filename_charset =	boolean;
	       This field may be used to limit the characters
	       allowed in filenames to only those explicitly
	       allowed by POSIX.  Defaults to false if not set.

	       For a filename to be portable across conforming
	       implementations of IEEE Std 1003.1-1988,	it shall
	       consist only of alphanumeric characters,	dot,
	       hyphen or underscore.  Hyphen shall not be used as
	       the first character of a	portable filename.

	       If this field is	false, all characters are allowed
	       except non-printing characters, space characters
	       and leading hyphens.

       dos_filename_required = boolean;
	       This field may be used to limit filenames so that
	       they conform to the DOS 8+3 filename limits and to
	       the DOS filename	character set.	Also denies
	       filenames which look like devices (AUX, _e_t_c).
	       Defaults	to false if not	set.  This field is used
	       in combination with the other filename fields, it
	       does not	replace	them.

       windows_filename_required = boolean;
	       This field may be used to limit filenames so that
	       they conform to the Windows98 and WindowsNT
	       filename	limits and character set.  Also	denies
	       filenames which look like devices (AUX, _e_t_c).
	       Defaults	to false if not	set.  This field is used
	       in combination with the other filename fields, it
	       does not	replace	them.

       shell_safe_filenames = boolean;
	       This field may be used to limit filenames so that
	       they may	not contain shell special characters.  If
	       you do not set this to true, you	will need to use
	       the ${quote} substitution around	filenames in
	       commands, or risk unexpected errors.  This field
	       defaults	to true	if not set.

       filename_pattern_accept = [ string ];
	       This field is used to specify a list of patterns
	       of acceptable filenames.	 The patterns are matched
	       against each filename path element.  The	patterns
	       are constructed from the	usual shell filename
	       wildcards.  Defaults to "*" if not set.

       filename_pattern_reject = [ string ];
	       This field is used to specify a list of patterns
	       of unacceptable filenames.  The patterns	are
	       matched against each filename path element.  The
	       patterns	are constructed	from the usual shell
	       filename	wildcards.  Defaults to	"*,D" if not set.
	       The pattern "*,D" is always appended.  Where the
	       _f_i_l_e_n_a_m_e___p_a_t_t_e_r_n___a_c_c_e_p_t and
	       filename_pattern_reject fields conflict,	the
	       reject takes precedence.

       new_test_filename = string;
	       This field is used to form the filename of new
	       tests, where the	filename is not	specified on the
	       aent command line.  Defaults to "test/${zpad
	       $hundred	2}/t${zpad $number 4}${left $type 1}.sh"
	       if not set.

	       All of the substitutions	defined	in _a_e_s_u_b(5) are
	       available.  The following three substitutions are
	       also available:

	       $Hundred
		       The test	number divided by 100, optional

	       $Number The test	number,	mandatory

	       $Type   The test	type: "automatic" or "manual",
		       optional

       development_directory_template =	string;
	       This field is used to determine the name	of the
	       development directory at	develop	begin.	All of
	       the substitutions defined in aesub(5) are
	       available.  The following substitutions is also
	       available:

	       Default_Development_Directory
		       The directory within which the development
		       directory is to be created.

	       Magic   A single	letter,	starting from ``C'',
		       which can be inserted.  This must be used,
		       as it allows Aegis to try different names
		       should there be a conflict.

	       If not set, defaults to "$ddd/${left $p ${expr
	       ${namemax $ddd} - ${length .$magic$c}}}.$magic$c".

	       For DOS compatibility (8+3 filenames), a	useful
	       setting is "$ddd/${downcase ${left ${id $p}
	       8}.$magic${right	0$c 2}}".  This	ensures	that the
	       filename	is always a valid 8.3 filename,	that it
	       is always lowercase, and	it translates any
	       punctuation in the project name into underscores.


       metrics_filename_pattern	= string;
	       This field is used to form the name of the metrics
	       file, given a source file.  All of the
	       substitutions defined in	aesub(5) are available.
	       The following substitutions is also available:

	       File_Name
		       The absolute pathname of	the source file.

	       Defaults	to "$filename,S" if not	set.

       trojan_horse_suspect = [	string ];
	       This list of filename patterns is consulted by
	       aedist --receive	when it	is checking for	files
	       which could be used to host Trojan horse	attacks.
	       This will be different for different projects, so
	       you will	need to	update this youself.  The
	       patterns	are matched against the	whole filename;
	       naming only the last filename path element will
	       _n_o_t work	(unless	the pattern starts with	``*'').

       project_specific	= [ { ... } ];
	       This is a list of name and value	pairs for use
	       within the ${project-specific} substitution (see
	       _a_e_s_u_b(5)	for more information).	The sub-fields
	       are

	       name = string;
		       The name	of the value.

	       value = string;
		       The value to be substituted.

	       There are almost	no limitations on the strings
	       which may appear	in either of these fields.

OOBBSSOOLLEETTEE FFIIEELLDDSS
       There are some obsolete fields in the file.  They are
       provided	for backwards compatibility only, and should not
       be used.

       diff3_command = string;
	       This field is used to difference	3 files.  The
	       command is always executed by developers.  Used by
	       the _a_e_d(1) command.  All	of the substitutions
	       described by _a_e_s_u_b(5) are available; in addition,

	       ${ORiginal}
		       The absolute path of the	original file
		       copied into the change.	Usually	not in
		       the baseline.

	       ${Most_Recent}
		       The absolute path of the	competing edit,
		       usually in the baseline.

	       ${Input}
		       The absolute path of the	file in	the
		       development directory.

	       ${Output}
		       The absolute path of the	file in	which to
		       write the difference listing.

	       Executed	as: the	project	owner (for integration
	       diffs), or the developer	(for development diffs).
	       Current directory: the integration directory (for
	       integration diffs), or the development directory
	       (for development	diffs).	 Exit status: zero
	       indicates succes, all non-zero exits indicate
	       failure (the aed	will fail).

	       The problem with	this field was that the	default
	       usage placed the	merged source in a strange place.
	       And subsequent _a_e_d(1) commands would over-write
	       it.  This meant that merges would be lost, causing
	       a number	of nasty problems.  Some sites overcame
	       this by adding ``mv'' commands to put the output
	       back where the input came from, but this	meant
	       that Aegis' commentary was misleading.  Use the
	       ``merge_command'' field instead.	 It is almost
	       identical, but Aegis will move the files	around
	       for you - so you	get the	good behavior by default
	       (no lost	merges)	and the	error message is
	       consistent.

SSEEEE AALLSSOO
       _a_e_b(1)  build a change

       _a_e_c_p(1) copy a file into	a change

       _a_e_c_p_u(1)
	       reverse action of aecp

       _a_e_d(1)  find differences	between	a change and the baseline

       _a_e_d_e(1) end development of a change

       _a_e_i_b(1) begin integration of a change

       _a_e_i_p_a_s_s(1)
	       pass integration	of a change

       _a_e_m_v(1) rename a	file as	part of	a change

       _a_e_n_f(1) add new files to	be created by a	change

       _a_e_n_f_u(1)
	       remove new files	from a change

       _a_e_n_t(1) add a new test to be created by a change

       _a_e_n_t_u(1)
	       remove new tests	from a change

       _a_e_t(1)  run tests

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

       _a_e_s_u_b(5)
	       available command substitutions

       _a_e_t_e_s_t(5)
	       batch test results file


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