This field names a directory which will be searched for additional configuration files.  (This directive is only legal or meaningful in the master project config 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 "config" file.

The usual priority of files (development directory, branch baseline, etc, 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 consulted. 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 config 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.

This field describes how to build the project (actually, how to do an integration build). This field is mandatory. Used by the aeb(1) command. All of the substitutions described by aesub(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.

This field describes how to do a development build. If this field is absent, it defaults to the above. Used by the aeb(1) command. All of the substitutions described by aesub(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.

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. Note that the contents of the project baseline reflect content before the currently integrating change. In particular note that for the first delta in a project or branch, the baseline directory is empty. If data is required from the change just completed one must use the ${INTegration_Directory} substitution.

Exit status: NOT ignored. Note that a failure here puts the change in a partial state from which recovery may be difficult. Best to define this command with a set +e so that errors are ignored at the command level.

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

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.

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 create_%symlinks_%before_%build if not set.

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 create_%symlinks_%before_%build field is true, for the purpose of reversing the actions of the create_%symlinks_%before_%build field.

Defaults to false if not set.

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 create_%symlinks_%before_%integration_%build field is true, for the purpose of reversing the actions of the create_%symlinks_%before_%integration_%build field.

Defaults to true 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, caveat emptor.

This field contains a command to be executed whenever a '(n) -CoPy_file', '(n) -New_File' '(n) -New_Test' '(n) -MoVe_file' or '(n) -ReMove_file' command is successful. See also command-specific overrides. If this field is absent, nothing is done. Used by the aecp(1) , aenv(1) , aenf(1) , aerm(1) , and aemv(1) commands. All of the substitutions described by aesub(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.

This field contains a command to be executed whenever a '(n) -CoPy_file_Undo', '(n) -MoVe_file_Undo' '(n) -New_File_Undo', '(n) -New_Test_Undo', or '(n) -ReMove_file_Undo' command is successful. Default to change_%file_%command if absent. See also command-specific overrides. If both fields are absent, nothing is done. Used by the aecpu(1) , aemvu(1) , aenfu(1) , aentu(1) or aermu(1) , commands. All of the substitutions described by aesub(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.

Executed whenever the aegis -new_file command is run successfully. Defaults to `change_file_command' if not set.

All of the substitutions described in aesub(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.

Executed whenever the aegis -new_test command is run successfully. Defaults to `change_file_command' if not set.

All of the substitutions described in aesub(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.

Executed whenever the aegis -copy_file command is run successfully. Defaults to `change_file_command' if not set.

All of the substitutions described in aesub(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.

Executed whenever the aegis -remove_file command is run successfully. Defaults to `change_file_command' if not set.

All of the substitutions described in aesub(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.

Executed whenever the aegis -new_file_undo command is run successfully. Defaults to change_file_undo_command if not set.

All of the substitutions described in aesub(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.

Executed whenever the aegis -new_test_undo command is run successfully. Defaults to change_file_undo_command if not set.

All of the substitutions described in aesub(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

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 aesub(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

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 aesub(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

This field contains a command to be executed during a development build before the "development build command" 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 aeb(1) command. All of the substitutions described by aesub(5) are available.

This field contains a command to be executed whenever a '(n) -Develop_Begin' command is successful. If this field is absent, nothing is done. Used by the aedb(1) command. All of the substitutions described by aesub(5) are available.

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

This field contains a command to be executed whenever a '(n) -Develop_Begin_Undo' command is successful. If this field is absent, nothing is done. Used by the aedbu(1) command. All of the substitutions described by aesub(5) are available.

Executed as: the developer. Current directory: wherever the command was executed from. Exit status: ignored.

This field contains a command to be executed whenever a '(n) -Integrate_Begin' command is successful. If this field is absent, nothing is done. Used by the aeib(1) command. All of the substitutions described by aesub(5) are available.

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

This field is used to create a new history. The command is always executed as the project owner. Used by the aeipass(1) command.

It is strongly recommended that the history_%create_%command and history_%put_%command fields are identical.  If not set, the history_%create_%command field defaults to the same value as the history_%put_%command field.

All of the substitutions described by aesub(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 Dirname and Basename substitutions to yield a string suitable for the history tool in question.

See also the history_put_trashes_file 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).

This field is used to get a file from history. The command may be executed by developers. Used by the aeipass(1) and aecp(1) commands. All of the substitutions described by aesub(5) are available; in addition,

${History}

The absolute path of the history file. This may need to be reworked with the Dirname and Basename 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 success, all non-zero exits indicate failure (the aecp will fail).

This field is used to add a new change to the history. The command is always executed as the project owner. Used by the aeipass(1) command.

It is strongly recommended that the history_%put_%command and history_%create__%command fields are identical.  If not set, the history_%put_%command field defaults to the same value as the history_%create_%command field.

All of the substitutions described by aesub(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 Dirname and Basename substitutions to yield a string suitable for the history tool in question.

See also the history_put_trashes_file 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).

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 aeipass(1) and aecp(1) commands. All of the substitutions described by aesub(5) are available; in addition,

${History}

The absolute path of the history file. This may need to be reworked with the Dirname and Basename 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).

This field contains a command to be executed whenever a aeipass(1) or aedn(1) command is successful. This command is invoked for every 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 aesub(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 executed from aeipass(1) this value is the same as ${Version}, which may need to be reworked with the ${Subst} substitutions to yield a string suitable for the history tool in question. When executed from aedn(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 history_%put_%command execution is required, which operates on one history file.  If you have labeling turned on, it will also be necessary to execute 10,000 history_%label_%commands, to add information Aegis will never use.

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 history_put_command or history_create_command . 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!

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 history_%create_%command or the history_%put_%command 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 history_get_command 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).

This field is used to difference of 2 files. The command is always executed by developers. Used by the aed(1) command. All of the substitutions described by aesub(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 success, all non-zero exits indicate failure (the aed will fail).

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 aed(1) command. All of the substitutions described by aesub(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 diff3_command 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).

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 aepatch(1) command.

Defaults to <[>CW]"set +e; diff -c -L $index -L $index $original $input > $output; text $? -le 1" if not set.

All of the substitutions described by aesub(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 development directory (for development diffs). Exit status: zero indicates succes, all non-zero exits indicate failure (the aed will fail).

The difference of 2 files, for the use of the aeannotate(1) command. (This isn't the same as the diff_%command field, because it's aimed at aeannotate(1) , not at humans.)  The command is always executed by developers.  Used by the aeannotate(1) command.

Extreme care should be taken if you are considering setting this field, otherwise the result reported by aeannotate(1) may bear little relation to reality. The most useful option is GNU diff's --ignore-all-space option, which will have the effect of ignoring the majority of indenting and code formatting changes.  The --ignore-case 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 - -ignore-blank-lines or --context as these will produce misleading results.

Defaults to <[>CW]"set +e; diff $option $original $input > $output; text $? -le 1" if not set.

All of the substitutions described by aesub(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 aeannotate(1) -diff-option 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 development directory (for development diffs). Exit status: zero indicates succes, all non-zero exits indicate failure (the aed will fail).

This field is used to set the command to be executed by the aet(1) command. Defaults to "$shell $file_name" if not set.

All of the substitutions described in aesub(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 aesub(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, except 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 -independent tests). Exit status: zero indicates success, one indicates failure, anything else indicates "no result".

This field is used to set the command to be executed by the aet(1) command when a change is in the "being developed" state. Defaults to be the same as the test_command field if not set.

Note: It is a significantly bad idea to make tests behave differently in "being development" and "being integrated" states; avoid this at all costs.

All of the substitutions described in aesub(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 aesub(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, except 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 success, one indicates failure, anything else indicates "no result".

This field is used to set the command to be executed by the aet(1) command, in preference to the test_command or development_test_command, if set.  It is capable of running more than one test at once.

All of the substitutions described in aesub(5) are available. In addition:

${Output}

This is the name of the file to be generated to hold the test results. See aetest(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 aesub(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, except 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.

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".

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 ${ARCHitecture} substitution (see aesub(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;

mode = (required, optional, forbidden);

If the architecture field is not set, it defaults to

pattern = [ string ];

The name of the file, relative to the development directory. Each string is a shell file name pattern; see sh(1) for more information. The patterns are matched against the whole filename; naming only the last filename path element will not work (unless the pattern starts with ``<[>CW]*'').

body_command = string;

body = string;

What to initialize the body of the file to.

All of the substitutions described in aesub(5) are available for the body and body_command strings. (Only specify one of them.) In addition:

${File_Name}

will be replaced by the name of the new file.

pattern = [ string ];

The name of the file, relative to the development directory. Each string is a shell file name pattern; see sh(1) for more information. The patterns are matched against the whole filename; naming only the last filename path element will not work (unless the pattern starts with ``<[>CW]*'').

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 aesub(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.

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 config file is in the change. See aede(1) for more information.

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.

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 aesub(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

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.

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.

This is a list of name and value pairs for use within the ${project-specific} substitution (see aesub(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.

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 relinked so that aet -reg does not give false negatives. Combining this with the project_%file_%command (above) can alleviate the vast majority of file modification time inconsistencies 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, project_%file_%command 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 mucho productivity. You have been warned. See also the build_%time_%adjust_%notify_%command field.

This field is used to difference 3 files. The command is always executed by developers. Used by the aed(1) command. All of the substitutions described by aesub(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 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 aed(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.