aepconf(5)		      File Formats Manual		    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/aegis.conf _(_d_e_f_a_u_l_t_)
	_p_r_o_j_e_c_t/baseline/config	_(_o_b_s_o_l_e_t_e_)

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.

	As of aegis.4.17, it is	possible to assign any arbitrary name to the
	project	configuration file or files.  See _a_e_n_f(1) for more informa-
	tion.

	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	com-
	mands in unintended ways.  There are two main sources of these prob-
	lems: file names and architecture names.  In order to have shell spe-
	cial 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.

   GGeettttiinngg SSttaarrtteedd
	Because	the project _a_e_g_i_s_._c_o_n_f file is under source control like any
	other file, you	must create the	project	_a_e_g_i_s_._c_o_n_f file	in the very
	first change of	your project.  Use the
		$ aaeennff aaeeggiiss..ccoonnff
		$
	command	and then editing the file to fill in the fields.  Subsequent
	Aegis commands in that change will use that file.  Once	the change is
	completed (see _a_e_i_p_a_s_s(1) for more information)	the file will be
	present	in the baseline, and be	used by	all users and all changes.

	If you ever need to change one of the fields of	the project _a_e_g_i_s_._c_o_n_f
	file, you do this the same way as for any other	source file, by	copy-
	ing it into a change using the
		$ aaeeccpp aaeeggiiss..ccoonnff
		$
	command	and then edit the file to make the desired changes.  While
	it's _b_e_i_n_g _d_e_v_e_l_o_p_e_d your change will use it's copy of the project
	_a_e_g_i_s_._c_o_n_f file, but once the change is	completed (see _a_e_i_p_a_s_s(1) for
	more information), it becomes the new version used by all users	and
	changes.

	If you would prefer a different	name for the project configuration
	file, use the _a_e_n_f _-_c_o_n_f_i_g option.  For	example, the
		$ aaeennff --ccoonnffiigg pprroojjeecctt..ccoonnffiigguurraattiioonn
		$
	command	would create a file called _p_r_o_j_e_c_t_._c_o_n_f_i_g_u_r_a_t_i_o_n and Aegis
	would then proceed to use it to	obtain project configuration informa-
	tion for the duration of the project.  This attribute will even	be
	preserved across file renames (see the _a_e_m_v(1) command).

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

	configuration_directory	= string;
		This field names a directory which will	be searched for	addi-
		tional configuration files.  (This directive is	only legal or
		meaningful in the master project _a_e_g_i_s_._c_o_n_f file.)

		All source files (change source	files and project source
		files) present in this directory will be read in as if they
		were added to the end of the project "aegis.conf" file.

		The usual priority of files (development directory, branch
		baseline, _e_t_c, project trunk baseline) is observed when	these
		files are read.

		Please note that the physical directories are never searched,
		only the Aegis concept of the change and project files is con-
		sulted (_i_._e_.  files created and	modified in the	usual way with
		_a_e_n_f(1)	and _a_e_c_p(1) commands).	Placing	additional files in
		the physical directories will have no effect.

		It is recommended that if you use this field at	all, that your
		top level project _a_e_g_i_s_._c_o_n_f file should only contain this one
		field.	This is	to avoid overly-large re-reading of this file
		when it	is joined to all the others.

	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 integrator (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 success, non-zero is
		a failure and a	subsequent successful (exit zero) build	will
		be required.

		If this	field is set to	"exit 0" then no integration build
		will be	required, and will not be checked for by the
		_a_e_i_p_a_s_s(1) command.

	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 develop-
		ment 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.

		If this	field is set to	"exit 0" then no development build
		will be	required, and will not be checked for by the _a_e_d_e(1)
		command.

	development_directory_style = {	... };
		This field encapsulates	a set of parameters controlling	the
		appearance of the development directory.  It has significant
		implications for the way the DMT is used, and the directory
		appearance presented to	the DMT.

		source_file_link = boolean;
			This field is true if hard links are to	be used	for
			project	source files (which are	not part of the
			change)	so that	the work area has a complete set of
			source files.

			Defaults to false if not set.

			If the host system does	not have hard links, this
			field will be ignored.

			Maintaining the	hard links can be time consuming for
			large projects,	and add	quite a	noticeable delay
			before builds start doing anything.  If	possible,
			change your build system to use	the _$_s_e_a_r_c_h___p_a_t_h sub-
			stitution instead and avoid links.

		source_file_symlink = boolean;
			This field is true if symbolic links are to be used
			for project source files (which	are not	part of	the
			change)	so that	the work area has a complete set of
			source files.

			Defaults to false if not set.  [If the obsolete
			_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 set, defaults to
			the value of that field, with a	warning.]

			If (_s_o_u_r_c_e___f_i_l_e___l_i_n_k ==	true aanndd hard links are	avail-
			able) this field will be ignored.  If the host system
			does not have symbolic links, this field will be
			ignored.

			Maintaining the	symbolic links can be time consuming
			for large projects, and	add quite a noticeable delay
			before builds start doing anything.  If	possible,
			change your build system to use	the _$_s_e_a_r_c_h___p_a_t_h sub-
			stitution instead and avoid symbolic links.

		source_file_copy = boolean;
			This field is true if copies are to be used for
			project	source files (which are	not part of the
			change)	so that	the work area has a complete set of
			source files.  File modification time attributes will
			be preserved.

			Defaults to false if not set.

			If ((_s_o_u_r_c_e___f_i_l_e___l_i_n_k == true aanndd hard links are
			available) OR (_s_o_u_r_c_e___f_i_l_e___s_y_m_l_i_n_k == true aanndd sym-
			bolic links are	available)) this field will be
			ignored.

			Maintaining the	copies can be time consuming (and
			space consuming) for large projects, and add quite a
			noticeable delay before	builds start doing anything.
			If possible, change your build system to use the
			_$_s_e_a_r_c_h___p_a_t_h substitution instead and avoid file
			copies.

		source_file_whiteout = boolean;
			The _s_o_u_r_c_e___f_i_l_e___w_h_i_t_e_o_u_t field mat be used to specify
			the presence (true) or absence (false) of white-out
			files, used to "cover up" files	being removed by a
			change set.  These files contain 1kB of	random data,
			intended to cause a syntax error should	be build ref-
			erence them.

			It is rarely necessary to explicitly set this field.
			It defaults to false if	you set	any of the
			_s_o_u_r_c_e___f_i_l_e___l_i_n_k, _s_o_u_r_c_e___f_i_l_e___s_y_m_l_i_n_k or
			_s_o_u_r_c_e___f_i_l_e___c_o_p_y to true; it defaults to true only if
			none of	them are true.

			Not meaningful (always false) for integration builds.

		derived_file_link = boolean;
			This field is true if hard links are to	be used	for
			non-source files which are present in the project
			baseline(s) but	which are not present in the work
			area, so that the work area has	a complete set of
			derived	files.	This allows work areas to take advan-
			tage of	"precompiled" object files (_e_t_c) in the	base-
			line(s).

			Defaults to false if not set.

			If the host system does	not have hard links, this
			field will be ignored.

			Maintaining the	links can be time consuming for	large
			projects, and add quite	a noticeable delay before
			builds start doing anything.  If possible, change your
			build system to	use the	_$_s_e_a_r_c_h___p_a_t_h substitution
			instead	and avoid hard links.  Alternatively, set
			_d_e_r_i_v_e_d___a_t___s_t_a_r_t___o_n_l_y _=	_t_r_u_e_; and your work area will
			get a "head start" but the derived files will not be
			checked	for every build, but this will occasionally
			result in long build times after integrations.

			See also the _i_n_t_e_g_r_a_t_e___b_e_g_i_n___e_x_c_e_p_t_i_o_n_s	and _s_y_m_l_i_n_k___-
			_e_x_c_e_p_t_i_o_n_s fields (they	apply to hard links as well as
			symbolic links).

		derived_file_symlink = boolean;
			This field is true if symbolic links are to be used
			for non-source files which are present in the project
			baseline(s) but	which are not present in the work
			area, so that the work area has	a complete set of
			derived	files.	This allows work areas to take advan-
			tage of	"precompiled" object files (etc) in the	base-
			line(s).

			Defaults to false if not set.  [If the obsolete
			_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 set, defaults to
			the value of that field, with a	warning.]

			If (_d_e_r_i_v_e_d___f_i_l_e___l_i_n_k == true aanndd hard links are
			available) this	field will be ignored.	If the host
			system does not	have symbolic links, this field	will
			be ignored.

			Maintaining the	symbolic links can be time consuming
			for large projects, and	add quite a noticeable delay
			before builds start doing anything.  If	possible,
			change your build system to use	the _$_s_e_a_r_c_h___p_a_t_h sub-
			stitution instead and avoid symbolic links.  Alterna-
			tively,	set _d_e_r_i_v_e_d___a_t___s_t_a_r_t___o_n_l_y _= _t_r_u_e_; and your
			work area will get a "head start" but the derived
			files will not be checked for every build, occasion-
			ally resulting in long build times after integrations.

			See also the _i_n_t_e_g_r_a_t_e___b_e_g_i_n___e_x_c_e_p_t_i_o_n_s	and _s_y_m_l_i_n_k___-
			_e_x_c_e_p_t_i_o_n_s fields.

		derived_file_copy = boolean;
			This field is true if copies are to be used for	non-
			source files which are present in the project base-
			line(s)	but which are not present in the work area, so
			that the work area has a complete set of derived
			files.	This allows work areas to take advantage of
			"precompiled" object files (_e_t_c) in the	baseline(s).

			Defaults to false if not set.

			If ((_d_e_r_i_v_e_d___f_i_l_e___l_i_n_k == true aanndd hard	links are
			available) oorr (_d_e_r_i_v_e_d___f_i_l_e___s_y_m_l_i_n_k == true aanndd	sym-
			bolic links are	available)) this field will be
			ignored.

			Maintaining the	copies can be time consuming (and
			space consuming) for large projects, and add quite a
			noticeable delay before	builds start doing anything.
			If possible, change your build system to use the
			_$_s_e_a_r_c_h___p_a_t_h substitution instead and avoid symbolic
			links.	Alternatively, set _d_e_r_i_v_e_d___a_t___s_t_a_r_t___o_n_l_y _=
			_t_r_u_e_; and your work area will get a "head start" but
			the derived files will not be checked for every	build,
			occasionally resulting in long build times after inte-
			grations.

			See also the integrate_begin_exceptions	and sym-
			link_exceptions	fields (they apply to copies as	well
			as symbolic links).

		during_build_only = boolean;
			This field is set to true if you want the symbolic
			links, hard links and/or copies	removed	again after
			each build.  This allows the user to maintain the
			illusion of using a search path, without actually
			doing so.  This	option is not especially efficient.

			Defaults to false if not set.  [If the obsolete
			_r_e_m_o_v_e___s_y_m_l_i_n_k_s___a_f_t_e_r___b_u_i_l_d field is set, defaults to
			the value of that field, with a	warning.]

			If this	field is false,	the development	directory will
			be populated by	the develop begin (_a_e_d_b) command, and
			the integration	directory will be populated by the
			integrate begin	(_a_e_i_b) command.

		derived_at_start_only =	boolean;
			This field controls whether the	above fields control-
			ling the appearance of derived files are acted upon
			before every build (false) or only when	the work area
			is created (true).

			Defaults to false if not set.

			This field is ignored if the _d_u_r_i_n_g___b_u_i_l_d___o_n_l_y field
			is true.

		This field can be complex.  Here are a few examples; but much,
		much more is possible.	The first example will get you a
		development directory very similar to one presented by CVS:
			development_directory_style =
			{
			    source_file_copy = true;
			};
		Note that this is hugely space inefficient, and	can be quite
		slow.  The second example will get you a development directory
		very similar to	one presented by Tom Lord's _a_r_c_h:
			development_directory_style =
			{
			    source_file_link = true;
			    source_file_symlink	= true;
			    source_file_copy = true;
			};
		Ideally, however, you should use the _$_s_e_a_r_c_h___p_a_t_h substitution
		of the _b_u_i_l_d___c_o_m_m_a_n_d field.  This is because the view path
		scales better than any other method.  On the other hand, you
		need a DMT with	an excellent view path implementation (and GNU
		_m_a_k_e doesn't).

		The development	directory style	is applied _a_f_t_e_r the develop_-
		begin_command hook is run.

	integration_directory_style = {	... };
		This field encapsulates	a set of parameters controlling	the
		appearance of the integration directory.  It has significant
		implications for the way the DMT is used, and the directory
		appearance presented to	the DMT.

		Defaults to the	value of the _d_e_v_e_l_o_p_m_e_n_t___d_i_r_e_c_t_o_r_y___s_t_y_l_e field
		if not set.  Note that the obsolete _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 and _r_e_m_o_v_e___s_y_m_l_i_n_k_s___a_f_t_e_r___i_n_t_e_g_r_a_t_i_o_n___b_u_i_l_d
		fields affect this default (with a warning) but	only if	they
		are _e_x_p_l_i_c_i_t_l_y set.

		Note that the _l_i_n_k___i_n_t_e_g_r_a_t_i_o_n___d_i_r_e_c_t_o_r_y field is still	rele-
		vant.  That field controls how the baseline is cloned to form
		the integration	directory.  This field operates	after that
		operation.

	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 mod-
		ification times, this command gives you	the opportunity	to re-
		sync the associated database.

		Executed as: the project owner.

		Current	directory: the integration directory.  This is what is
		about to be come the new baseline.

		Exit status: NOT ignored. Note that a failure here puts	the
		change in a partial state from which recovery may be diffi-
		cult. Best to define this command with a _s_e_t+e so that errors
		are ignored at the command level.

	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-compila-
		tion techniques, or Cook's ability to nominate hosts on	which
		to execute each	build rule.

	test_covers_all_architectures =	boolean;
		This field is set to true if the test command, when executed
		on any architecture, results in	all architectures being
		tested.	 This may be accomplished, for example,	by using
		Cook's ability to nominate hosts on which to execute each test
		rule.

	symlink_exceptions = [ string ];
		This field is used to list filename patterns for which sym-
		bolic 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	'aegis
		-CoPy_file', 'aegis -New_File' 'aegis -New_Test' 'aegis
		-MoVe_file' or 'aegis -ReMove_file' command is successful.
		See also command-specific overrides.  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 develop-
		ment directory of the change.  Exit status: ignored.

	change_file_undo_command = string;
		This field contains a command to be executed whenever a	'aegis
		-CoPy_file_Undo', 'aegis -MoVe_file_Undo' 'aegis
		-New_File_Undo', 'aegis	-New_Test_Undo', or 'aegis
		-ReMove_file_Undo' command is successful.  Default to _c_h_a_n_g_e___-
		_f_i_l_e___c_o_m_m_a_n_d if	absent.	 See also command-specific overrides.
		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 develop-
		ment directory of the change.  Exit status: ignored.

	new_file_command = string;
		Executed whenever the aegis -new_file command is run success-
		fully.	Defaults to `change_file_command' if not set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

		Executed as: the developer.  Current directory:	the develop-
		ment directory of the change.  Exit status: ignored.

	new_test_command = string;
		Executed whenever the aegis -new_test command is run success-
		fully.	Defaults to `change_file_command' if not set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

		Executed as: the developer.  Current directory:	the develop-
		ment directory of the change.  Exit status: ignored.

	copy_file_command = string;
		Executed whenever the aegis -copy_file command is run success-
		fully.	Defaults to `change_file_command' if not set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

		Executed as: the developer.  Current directory:	the develop-
		ment directory of the change.  Exit status: ignored.

	remove_file_command = string;
		Executed whenever the aegis -remove_file command is run	suc-
		cessfully.  Defaults to	`change_file_command' if not set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

		Executed as: the developer.  Current directory:	the develop-
		ment directory of the change.  Exit status: ignored.

	new_file_undo_command =	string;
		Executed whenever the aegis -new_file_undo command is run suc-
		cessfully.  Defaults to	change_file_undo_command if not	set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

		Executed as: the developer.  Current directory:	the develop-
		ment directory of the change.  Exit status: ignored.

	new_test_undo_command =	string;
		Executed whenever the aegis -new_test_undo command is run suc-
		cessfully.  Defaults to	change_file_undo_command if not	set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

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

	copy_file_undo_command = string;
		Executed whenever the aegis -copy_file_undo command is run
		successfully.  Defaults	to change_file_undo_command if not
		set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

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

	remove_file_undo_command = string;
		Executed whenever the aegis -remove_file_undo command is run
		successfully.  Defaults	to change_file_undo_command if not
		set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

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

	make_transparent_command = string;
		The make_transparent_command is	executed whenever the aegis
		-make_transparent command is run successfully.	Defaults to
		change_file_command if not set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

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

	make_transparent_undo_command =	string;
		The make_transparent_undo_command is executed whenever the
		aegis -make_transparent_undo command is	run successfully.
		Defaults to change_file_undo_command if	not set.

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

		${File_List}
			Space separated	list of	files named (at	times, can be
			empty).

		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 develop-
		ment 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_early_command = string;
		This field contains a command to be executed at	the beginning
		of a 'aegis -Develop_Begin' command, immediately after the
		development directory has been created.	 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 develop-
		ment directory of the change.  Exit status: ignored.

		NNoottee:: This command is run from inside the lock,	so running _a_n_y
		Aegis command that modifies the	change state will cause	a
		deadlock.

	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 develop-
		ment directory of the change.  Exit status: ignored.

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

		Executed as: the developer.  Current directory:	wherever the
		command	was executed from.  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	inte-
		gration	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 cor-
		rupted.	 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 direc-
		tory.  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 pat-
		terns 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 substitu-
			tions to yield a string	suitable for the history tool
			in question.

		${File_Name}
			The base relative file name of the file	for this
			check-in.  Note	that the file name can vary over the
			lifetime of the	file as	it is renamed, but the history
			file name (above) never	varies.	 _D_o _n_o_t	_u_s_e this as
			the name of the	history	file.  ((OOppttiioonnaall))

		${UUID}	The universally	unique identifier of the source	file.
			This is	invariant for the lifetime of the file.	 _D_o
			_n_o_t _u_s_e	use this as the	name of	the history file.
			((OOppttiioonnaall))

		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 success, all
		non-zero exits indicate	failure	(the integrate pass will
		fail).

		Note: For projects created Aegis 4.26 or later,	it is possible
		to change the history tool used	by the project simply changing
		the various _h_i_s_t_o_r_y___*___c_o_m_m_a_n_d documented in this man page.  It
		is also	possible to change the history tool for	projects cre-
		ated with _a_e_i_m_p_o_r_t 4.26	or later, however the original tool
		must be	available to access older file's revisions.

	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 substitu-
			tions to yield a string	suitable for the history tool
			in question.

		${Edit}
			The edit number	to be extracted.  It may be an arbi-
			trary 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 success, 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 substitu-
			tions to yield a string	suitable for the history tool
			in question.

		${File_Name}
			The base relative file name of the file	for this
			check-in.  Note	that the file name can vary over the
			lifetime of the	file as	it is renamed, but the history
			file name (above) never	varies.	 _D_o _n_o_t	_u_s_e this as
			the name of the	history	file.  ((OOppttiioonnaall))

		${UUID}	The universally	unique identifier of the source	file.
			This is	invariant for the lifetime of the file.	 _D_o
			_n_o_t _u_s_e	use this as the	name of	the history file.
			((OOppttiioonnaall))

		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 success, all
		non-zero exits indicate	failure	(the integrate pass will
		fail).

	history_transaction_begin_command = string;
		The history_transaction_begin_command field is used to specify
		a command to be	run by _a_e_i_p_a_s_s(1) before any history create or
		history	put commands are run.  The default is to do nothing.

		All of the substitutions described in _a_e_s_u_b(5) are available.
		If you need a transaction ID, use the _$_v_e_r_s_i_o_n substitution.

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

	history_transaction_end_command	= string;
		The history_transaction_end_command field is used to specify a
		command	to be run by _a_e_i_p_a_s_s(1)	after any history create or
		history	put commands are run, but before any history query
		commands are run.  The default is to do	nothing.

		All of the substitutions described in _a_e_s_u_b(5) are available.
		If you need a transaction ID, use the _$_v_e_r_s_i_o_n substitution.

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

	history_transaction_abort_command = string;
		The history_transaction_abort_command field is used to specify
		a command to be	run by _a_e_i_p_a_s_s(1) to indicate that a transac-
		tion has been abandoned.  The default is to do nothing.

		All of the substitutions described in _a_e_s_u_b(5) are available.
		If you need a transaction ID, use the _$_v_e_r_s_i_o_n substitution.

		Executed as: the project owner.	 Current directory: the	base
		of the history tree.  Exit status: ignored (the	integrate pass
		has already failed).

	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 com-
		mand 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 substitu-
			tions 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 success, all
		non-zero exits indicate	failure	(the integrate pass will
		fail).

	history_label_command =	string;
		This field contains a command to be executed whenever a
		_a_e_i_p_a_s_s(1) or _a_e_d_n(1) command is successful.  This command is
		invoked	for eevveerryy file in the project.	So using it incurs a
		performance penalty.  If this field is absent, nothing is
		done.  All of the substitutions	described by _a_e_s_u_b(5) are
		available; in addition,

		${History}
			The absolute path of the history file.

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

		${Label}
			The label to  be attached to the history.  When	exe-
			cuted from _a_e_i_p_a_s_s(1) this value is the	same as	_$_{_V_e_r_-
			_s_i_o_n_}_, which may need to be reworked with the _$_{_S_u_b_s_t_}
			substitutions to yield a string	suitable for the his-
			tory tool in question.	When executed from _a_e_d_n(1) it
			is set to the value passed in from the command line.

		Executed as: the project owner.	 Current directory: the	base
		of the history tree.  Exit status: zero	indicates success, all
		non-zero exits indicate	failure	(a warning will	be issued).

		Labeling does not scale, so the	use of this command is not
		encouraged.  If	you have a project with	10,000 files, and a
		change modified	exactly	one of them, only one _h_i_s_t_o_r_y___p_u_t___-
		_c_o_m_m_a_n_d	execution is required, which operates on one history
		file.  If you have labeling turned on, it will also be neces-
		sary to	execute	10,000 _h_i_s_t_o_r_y___l_a_b_e_l___c_o_m_m_a_n_ds, to add informa-
		tion Aegis will	never use.

	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 modi-
		    fied 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	con-
			tain 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 exam-
		ined for conformance to	this limitation.  If there is a	prob-
		lem, the file is encoded in either quoted printable for
		MIME64,	whichever is smaller, before being given to the	his-
		tory 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	infor-
		mation.	 This is because each put could	use a different	encod-
		ing (although in practice, file	contents rarely	change that
		dramatically, and the same encoding is likely to be deduced
		every time).

		Please note that this field ddooeess nnoott apply to the _d_i_f_f___c_o_m_m_a_n_d
		or _m_e_r_g_e___c_o_m_m_a_n_d fields.

	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 develop-
		ment directory (for development	diffs).	 Exit status: zero
		indicates success, all non-zero	exits indicate failure (the
		aed will fail).

		NNoottee:: It is possible to	configure a project to omit the	diff
		step as	unnecessary, by	the following setting:
			diff_command = "exit 0";
		This disables all generation, checking and validation of dif-
		ference	file for each change source file.  The merge functions
		of the _a_e_d_i_f_f(1) command are unaffected	by this	setting.

	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 tempo-
			rary 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 his-
		tory.)

		Executed as: the project owner (for integration	diffs),	or the
		developer (for development diffs).  Current directory: the
		integration directory (for integration diffs), or the develop-
		ment directory (for development	diffs).	 Exit status: zero
		indicates success, 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 -L	$index -L $index $original
		$input > $output; test $? -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.

		${INDex}
			The project-relative name of the file, for use when
			the file name is embedded in the output.  (Optional.)

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

	annotate_diff_command =	string;
		The difference of 2 files, for the use of the _a_e_a_n_n_o_t_a_t_e(1)
		command.  (This	isn't the same as the _d_i_f_f___c_o_m_m_a_n_d field,
		because	it's aimed at _a_e_a_n_n_o_t_a_t_e(1), not at humans.)  The com-
		mand is	always executed	by developers.	Used by	the _a_e_a_n_n_o_-
		_t_a_t_e(1)	command.

		Extreme	care should be taken if	you are	considering setting
		this field, otherwise the result reported by _a_e_a_n_n_o_t_a_t_e(1) may
		bear little relation to	reality.  The most useful option is
		GNU diff's ----iiggnnoorree--aallll--ssppaaccee option, which will have the
		effect of ignoring the majority	of indenting and code format-
		ting changes.  The ----iiggnnoorree--ccaassee option	could also be useful
		for case insensitive languages such as FORTRAN or PL/1.	 Avoid
		options	which would alter the number of	lines, such as --
		--iiggnnoorree--bbllaannkk--lliinneess or ----ccoonntteexxtt as these will produce mis-
		leading	results.

		Defaults to "set +e; diff $option $original $input > $output;
		test $?	-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.

		${INDex}
			The project-relative name of the file, for use when
			the file name is embedded in the output.  (Optional.)

		${OPTion}
			Extra options to be passed to the diff command,	as set
			by the _a_e_a_n_n_o_t_a_t_e(1) --ddiiffff--ooppttiioonn command line option.
			Use with extreme care.

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

	review_policy_command =	string;
		This field is used to set the command to be executed by	the
		_a_e_r_p_a_s_s(1) command.  This command is useful in cases where the
		enterprise has determined that more than one review is neces-
		sary or	that the reviewer must be senior to the	developer,
		_e_t_c.  Defaults to "exit	0" if not set.

		The exit status	is examined.  An zero exit status (success)
		means that the change will proceed to the _a_w_a_i_t_i_n_g _i_n_t_e_g_r_a_t_i_o_n
		state; a non-zero exit status (failure)	means that the change
		requires further review	state, and the _d_e_v_e_l_o_p___e_n_d___a_c_t_i_o_n is
		consulted to determine the appropriate state (_a_w_a_i_t_i_n_g___r_e_v_i_e_w
		or _b_e_i_n_g___r_e_v_i_e_w_e_d) for the change to move to.

		All of the substitutions described by _a_e_s_u_b(5) are available.
		Of particular interest are ${Change_Developer_List} and
		${Change_Reviewer_List}	for passing the	specific staff
		involved with the change.

		Executed as: the current reviewer.  Current directory: the
		development directory.	Exit status: zero indicates success,
		non-zero indicates failure.

		For example, to	have a script which is a project source	file
		to be used to gate the code review process, a setting such as
		the following may be used:
			review_policy_command =
			    "$sh ${source script/reviewpolicy.sh} "
			    "-p	$project -c $change "
			    "-d	${developer_list} "
			    "-r	${reviewer_list}"
			    ;
		This is	only one of many ways to implement a project specific
		review policy.

	develop_end_policy_command = string;
		This field is used to set the command to be executed by	the
		_a_e_d_e(1)	command.  This command is useful in cases where	the
		enterprise has determined that additional pre-conditions must
		be met (in addition to those already imposed by	the _a_e_d_e(1)
		command) before	a change may leave the _b_e_i_n_g _d_e_v_e_l_o_p_e_d state.
		Defaults to "exit 0" if	not set.

		The exit status	is examined.  An zero exit status (success)
		means that the change may leave	to the _b_e_i_n_g _d_e_v_e_l_o_p_e_d state;
		a non-zero exit	status (failure) means that the	change
		requires further development.

		All of the substitutions described by _a_e_s_u_b(5) are available.

		Executed as: the developer.  Current directory:	the develop-
		ment directory.	 Exit status: zero indicates success, non-zero
		indicates failure.

		There are some common validations available in the _a_e_d_e_-_p_o_l_-
		_i_c_y(1) command;	you may	choose all or only some	of them, or
		you may	choose to write	a policy command specific to your
		project.

	unchanged_file_develop_end_policy = (...);
		This field may be used to control what happens when develop-
		ment of	a change is ended, and the change contains files which
		have not had their contents or their attributes	changed.

		ignore	Does not look for or warn about	unchanged files.  This
			the default.

		warning	If the change sets contains unchanged files, a warning
			will be	issued for each	one.

		error	If the change set contains unchanged files, an error
			will be	issued for each	one, and develop end will not
			complete (the change will remain in the	_b_e_i_n_g _d_e_v_e_l_-
			_o_p_e_d state).

	unchanged_file_integrate_pass_policy = (...);
		This field may be used to control what happens when a change
		is completed, and the change contains files which have not had
		their contents or their	attributes changed.

		ignore	Does not look for or warn about	unchanged files.  The
			file version will be added to the history.  This the
			default.

		warning	If the change sets contains unchanged files, a warning
			will be	issued for each	one.  The file version will be
			added to the history.

		remove	If the change set contains an unchanged	file, it will
			be silently removed from the change set.  The file
			version	will not be added to the history.  The project
			file is	unaffected.

	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 exe-
			cutable	files and executable support files.  Usually
			it is the same as the above, _e_x_c_e_p_t during an "aet
			-bl" command.

		${VARiables}
			The text of name=value variable	settings from the com-
			mand line, suitably quoted to protect special charac-
			ter from the shell.  Will be appended to the end of
			the command if not used	explicitly.

		Note that tests	are source files, and thus never have the exe-
		cute 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 -independent tests).  Exit sta-
		tus: zero indicates success, 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 dif-
		ferently 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 exe-
			cutable	files and executable support files.  Usually
			it is the same as the above, _e_x_c_e_p_t during an "aet
			-bl" command.

		${VARiables}
			The text of name=value variable	settings from the com-
			mand line, suitably quoted to protect special charac-
			ter from the shell.  Will be appended to the end of
			the command if not used	explicitly.

		Note that tests	are source files, and thus never have the exe-
		cute bit set.

		Executed as: the developer.  Current directory:	the develop-
		ment directory (for development	tests),	the project baseline
		(for -bl tests).  Exit status: zero indicates success, 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 exe-
			cutable	files and executable support files.  Usually
			it is the same as the above, _e_x_c_e_p_t during an "aet
			-bl" command.

		${Current}
			Number of first	test in	the batch.

		${Total}
			Total number of	tests. If this is 0 then no progress
			messages should	be issued.

		${VARiables}
			The text of name=value variable	settings from the com-
			mand line, suitably quoted to protect special charac-
			ter from the shell.  Will be appended to the end of
			the command if not used	explicitly.

		Note that tests	are source files, and thus never have the exe-
		cute 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 -independent tests).  Exit sta-
		tus: zero indicates success, one indicates failure, anything
		else indicates "no result".

	architecture_discriminator_command = string;
		If this	field is present it is used as a command to be exe-
		cuted in order to further identify the platform	architecture
		(see below).  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: zero indicates
		success, all non-zero exits indicate failure.

	architecture = [{ ... }];
		This field is a	list of	system and machine architectures on
		which each change must successfully build and test.  May be
		assigned more than once.  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 architec-
			ture, 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", or "_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--_d_i_s_c" if _a_r_c_h_i_t_e_c_t_u_r_e___d_i_s_c_r_i_m_i_n_a_t_o_r___c_o_m_m_a_n_d is
			used.

			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 archi-
				tectures 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.  May	be assigned
		more than once.	 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 cre-
			ated.

		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 file names.  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 _a_e_g_i_s_._c_o_n_f 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 file
		names to only those explicitly allowed by POSIX.  Defaults to
		false if not set.

		For a filename to be portable across conforming	implementa-
		tions 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 file-
		name.

		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	file names so that they	con-
		form to	the DOS	8+3 filename limits and	to the DOS filename
		character set.	Also denies file names 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	file names so that they	con-
		form to	the Windows98 and WindowsNT filename limits and	char-
		acter set.  Also denies	file names 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	file names 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
		file names in commands,	or risk	unexpected errors.

		This field defaults to true if not set.

		The white space	characters (space, tab,	newline, _e_t_c) are con-
		sidered	shell special characters.

	allow_white_space_in_filenames = boolean;
		This field may be used to allow	white space characters in file
		names.	This will allow	the following characters to appear in
		filenames: backspace (BS, \b, 0x08), horizontal	tab (HT, \t,
		0x09), new line	(NL, \n, 0x0A),	vertical tab (VT, \v, 0x0B),
		form feed (FF, \f, 0x0C), and carriage return (CR, \r, 0x0D).

		Defaults to false if not set.

		Note that this field does not override other file name fil-
		ters.  It will be necessary to explicitly set _s_h_e_l_l___s_a_f_e___-
		_f_i_l_e_n_a_m_e_s _= _f_a_l_s_e as well.  It will be necessary to set	_d_o_s___-
		_f_i_l_e_n_a_m_e___r_e_q_u_i_r_e_d _= _f_a_l_s_e (the default)	as well.  It will be
		necessary to set _p_o_s_i_x___f_i_l_e_n_a_m_e___c_h_a_r_s_e_t	_= _f_a_l_s_e	(the default)
		as well.

		The user must take great care to use the ${quote} substitution
		around all file	names in commands in the project configura-
		tion.  And even	then, substitutions which expect a space sepa-
		rated list of file names will have undefined results.

	allow_non_ascii_filenames = boolean;
		This field may be used to allow	file names with	non-ascii-
		printable characters in	them.  Usually this would mean a UTF8
		or international charset of some kind.

		Defaults to false if not set.

		Note that this field does not override other file name fil-
		ters.  It will be necessary to explicitly set _s_h_e_l_l___s_a_f_e___-
		_f_i_l_e_n_a_m_e_s _= _f_a_l_s_e as well.  It will be necessary to set	_d_o_s___-
		_f_i_l_e_n_a_m_e___r_e_q_u_i_r_e_d _= _f_a_l_s_e (the default)	as well.  It will be
		necessary to set _p_o_s_i_x___f_i_l_e_n_a_m_e___c_h_a_r_s_e_t	_= _f_a_l_s_e	(the default)
		as well.

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

	filename_pattern_reject	= [ string ];
		This field is used to specify a	list of	patterns of unaccept-
		able file names.  The patterns are matched against each	file-
		name path element.  The	patterns are constructed from the
		usual shell filename wild-cards.  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 con-
		flict, 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 _a_e_s_u_b(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 file	names),	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 _a_e_s_u_b(5)
		are available.	The following substitutions is also available:

		File_Name
			The absolute path name 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 Tro-
		jan horse attacks.  This will be different for different
		projects, so you will need to update this yourself.  The pat-
		terns 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	infor-
		mation).  May be assigned more than once.  The sub-fields are

		name = string;
			The name of the	value.	By convention, names which
			start with an upper-case letter	will appear in list-
			ings, and lower-case will not.	Attribute names	are
			case-insensitive.

		value =	string;
			The value to be	substituted.

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

		There are several attribute names which	are known to and used
		by Aegis, these	include:

		aede-policy
			This attribute is used when no policy names are	listed
			on the _a_e_d_e_-_p_o_l_i_c_y(1) command line.

		ae-repo-ci:commit-message
			See _a_e_-_r_e_p_o_-_c_i(1) for more information.

		aede-policy
			See _a_e_d_e_-_p_o_l_i_c_y(1) for more information.

		aede-policy:version-info:library
			See _a_e_d_e_-_p_o_l_i_c_y(1) for more information.

		aeget:inventory:hide
			See _a_e_g_e_t(1) for more information.

		aemakegen:debian:build-depends
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:copyright
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:depends
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:description:_n_a_m_e
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:extended-description:_n_a_m_e
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:homepage
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:maintainer
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:priority
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:debian:section
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:pkg-config:cflags
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:pkg-config:conflicts
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:pkg-config:libs
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:pkg-config:libs.private
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:pkg-config:requires
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aemakegen:version-info
			See _a_e_m_a_k_e_g_e_n(1) for more information.

		aetar:exclude
			This attribute is used by he _a_e_t_a_r(1) receive command
			to exclude files in tarballs from consideration.  This
			is a space separated list of file names.

		copyright-owner
			This string is available via the _$_{_c_o_p_y_r_i_g_h_t_-_o_w_n_e_r_}
			substitution, and is the one checked by	the _a_e_d_e_-_p_o_l_-
			_i_c_y(1) command.	 Only set this attribute if your
			project	is a work-for-hire under copyright law.	 It
			defaults to the	value of _$_{_u_s_e_r	_n_a_m_e_} if not set, this
			is almost always correct for Open Source projects.

		html:body-begin
			This attribute is used by the _a_e_g_e_t(1) command to cus-
			tomize generated web pages.  See _a_e_g_e_t(1) for more
			information.

		html:meta
			This attribute is used by the _a_e_g_e_t(1) command to cus-
			tomize generated web pages.  See _a_e_g_e_t(1) for more
			information.

		html:body-end
			This attribute is used by the _a_e_g_e_t(1) command to cus-
			tomize generated web pages.  See _a_e_g_e_t(1) for more
			information.

		svn:password
			See _a_e_-_r_e_p_o_-_c_i for more	information.

		svn:username
			See _a_e_-_r_e_p_o_-_c_i for more	information.

		When commands are executed by Aegis, it	ensures	that the
		AEGIS_PROJECT, AEGIS_CHANGE, AEGIS_ARCH, LINES and COLS	envi-
		ronment	variables are set appropriately.  The project configu-
		ration file's _p_r_o_j_e_c_t___s_p_e_c_i_f_i_c field is	also consulted,	look-
		ing for	value's	whose name starts with "setenv:" and sets the
		corresponding environment variable.  All of the	substitutions
		described by _a_e_s_u_b(5) are available.  For example: specifying
		a PATH and a SEARCH_PATH to be used for	all commands may be
		set as follows:
			project_specific =
			[
			  {
			    name = "setenv:PATH";
			    value = "/usr/bin:/bin";
			  },
			  {
			    name = "setenv:SEARCH_PATH";
			    value = "${search_path}";
			  },
			];
		As many	environment variables as desired may be	specified in
		this way.

	build_time_adjust = (...);
		This field controls the	adjustment of file modification	times
		at the end of integrate-pass.  File times are adjusted so that
		development directories	are, in	the main, out of date with
		respect	to the baseline.  The idea is that, at the very	least,
		programs need to be re-linked so that _a_e_t _-_r_e_g does not	give
		false negatives.

		Combining this with the	_p_r_o_j_e_c_t___f_i_l_e___c_o_m_m_a_n_d (above) can alle-
		viate the vast majority	of file	modification time inconsisten-
		cies experienced as a result of	a project integration and the
		subsequent changes in the baseline's file modification times.

		Unless you are a masochist, do not set this field.  Leave it
		as the default.

		adjust_and_sleep
			Causes the file	times to be adjusted, and if the file
			times would extend into	the future, aeipass will sleep
			until that time	has passed.  This is the default.

		adjust_only
			Causes the file	times to be adjusted.  If the file
			time extend into the future, a warning is issued.

		dont_adjust
			File modification times	are not	adjusted.  This	is a
			really bad idea.  Really.  Make	sure that, at the very
			minimum, _p_r_o_j_e_c_t___f_i_l_e___c_o_m_m_a_n_d touches all of the
			change's files,	otherwise the build problems which
			ensue are going	to take	you weeks to track down	and
			lose you much productivity.  You have been warned.

		See also the _b_u_i_l_d___t_i_m_e___a_d_j_u_s_t___n_o_t_i_f_y___c_o_m_m_a_n_d field.

	signed_off_by =	boolean;
		If this	field is set each _a_e_d_b(1), _a_e_c_h_o_w_n(1), _a_e_d_e(1) and
		_a_e_r_p_a_s_s(1) will	append a Signed-off-by line to the change
		description.  This field should	only be	set to true for	open
		source projects.

		For a description of Signed-off-by see
		http://www.ussg.iu.edu/hypermail/linux/kernel/0405.2/1301.html
		and http://www.osdl.org/news-
		room/press_releases/2004/2004_05_24_dco.html

	cache_project_file_list_for_each_delta = boolean;
		It is possible to have Aegis cache the list of project files
		that were present at integrate pass for	each delta (integrated
		change set).  This is used to optimize all project-history-
		based operations, such as _a_e_c_p _-_d_e_l_t_a or _a_e_p_a_t_c_h(1).

		This cache will	optimize many operations which would otherwise
		require	time to	reconstruct the	project	state using the	roll-
		forward	data available in each change set.  However, it	comes
		at the cost of disk space, and not everyone can	afford more
		and more disk.

		This field defaults to true if not set.

	clean_exceptions = [ string ];
		It is possible to have Aegis exclude from the clean process
		any file that match one	of the pattern listed in the
		clean_exceptions list.

		This field default to an empty list if not set.

	cache_project_file_list_for_each_delta = boolean;
		It is possible to have Aegis cache the list of project files
		that were present at integrate pass for	each delta (integrated
		change set).  This is used to optimize all project-history-
		based operations, such as _a_e_c_p _-_d_e_l_t_a or _a_e_p_a_t_c_h(1).

		This cache will	optimize many operations which would otherwise
		require	time to	reconstruct the	project	state using the	roll-
		forward	data available in each change set.  However, it	comes
		at the cost of disk space, and not everyone can	afford more
		and more disk.

		This field defaults to true if not set.

RRSSSS FFEEEEDDSS
	Aegis has the ability to feed RSS channels when	change sets transition
	states.	 See the User Guide for	full details.  Following is a brief
	description of the project-specific attributes used to control this
	process.

	Create / Add to	a channel
		An RSS channel is specified with the rss:feedfilename
		project_specific attribute:

		project_specific =
			[
			  {
			    name = "rss:feedfilename-<filename>";
			    value = "<space-separated list of states>";
			  }
			]

	Specify	the Description	of an RSS channel
		The description	of an RSS channel is specified with the
		rss:feeddescription project_specific attribute:

		project_specific =
			[
			  {
			    name = "rss:feeddescription-<filename>";
			    value = "<description>";
			  }
			]

	Specify	the Title of an	RSS channel
		The title of an	RSS channel is specified with the rss:feedti-
		tle project_specific attribute:

		project_specific =
			[
			  {
			    name = "rss:feedtitle-<filename>";
			    value = "<title>";
			  }
			]

	Specify	the Language of	an RSS channel
		The language of	an RSS channel is specified with the rss:feed-
		language project_specific attribute:

		project_specific =
			[
			  {
			    name = "rss:feedlanguage-<filename>";
			    value = "<language";
			  }
			]

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 develop-
		ment directory (for development	diffs).	 Exit status: zero
		indicates success, 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.

	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 imme-
		diately	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.

CCHHAANNGGIINNGG HHIISSTTOORRYY TTOOOOLL
	Since version Aegis 4.26 it is possible	to change the history tool, if
	needed.	 Note, however,	that the old tool is still required to
	retrieve file's	revisions saved	before the switch to the new tool.  As
	an example it is not advisable to uninstall the	_f_h_i_s_t package if a
	project	switched to _a_e_s_v_t, since _f_h_i_s_t will be required	to retrieve
	file's revisions pre-dating the	switch.

	The _a_e_i_p_a_s_s(1) command stores the _h_i_s_t_o_r_y___g_e_t___c_o_m_m_a_n_d as the
	_a_e_g_i_s_:_h_i_s_t_o_r_y___g_e_t___c_o_m_m_a_n_d user defined change's	attribute, that	com-
	mand will be used later	to retrieve files altered by the change.

	In any project created using Aegis v. 4.26 (or later) it is possible
	to use a different history tool	simply editing the appropriate _a_e_p_-
	_c_o_n_f(5)	fields.

	It is possible to change the history tool of projects created with a
	older Aegis version, but it's required to properly set the _a_e_g_i_s_:_h_i_s_-
	_t_o_r_y___g_e_t___c_o_m_m_a_n_d user defined attribute	for each change	integrated
	before the switch.

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_d_e_-_p_o_l_i_c_y(1) check things	about
		a change

	_a_e_r_p_a_s_s(1)
		pass a review 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 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			    aepconf(5)