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, 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 (i.e. files created and modified in the usual way with aenf(1) and aecp(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 aegis.conf 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.

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

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.

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

source_file_link = boolean;

source_file_symlink = boolean;

source_file_copy = boolean;

source_file_whiteout = boolean;

derived_file_link = boolean;

derived_file_symlink = boolean;

derived_file_copy = boolean;

during_build_only = boolean;

derived_at_start_only = boolean;

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;
};

development_directory_style =
{
    source_file_link = true;
    source_file_symlink = true;
    source_file_copy = true;
};

The development directory style is applied after the develop_begin_command hook is run.

Defaults to the value of the development_directory_style field if not set. Note that the obsolete create_symlinks_before_integration_build and remove_symlinks_after_integration_build fields affect this default (with a warning) but only if they are explicitly set.

Note that the link_integration_directory field is still relevant. That field controls how the baseline is cloned to form the integration directory. This field operates after that operation.

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 difficult. Best to define this command with a set+e so that errors are ignored at the command level.

${File_List}

Space separated list of files named.

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

${File_List}

Space separated list of files named.

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

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.

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.

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.

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.

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.

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

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

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

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

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 as: the developer. Current directory: the development directory of the change. Exit status: ignored.

Note: This command is run from inside the lock, so running any Aegis command that modifies the change state will cause a deadlock.

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

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

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

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.

${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. Do not use this as the name of the history file. (Optional)

${UUID}

The universally unique identifier of the source file. This is invariant for the lifetime of the file. Do not use use this as the name of the history file. (Optional)

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

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 history_*_command documented in this man page. It is also possible to change the history tool for projects created with aeimport 4.26 or later, however the original tool must be available to access older file's revisions.

${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).

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.

${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. Do not use this as the name of the history file. (Optional)

${UUID}

The universally unique identifier of the source file. This is invariant for the lifetime of the file. Do not use use this as the name of the history file. (Optional)

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

All of the substitutions described in aesub(5) are available. If you need a transaction ID, use the $version 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).

All of the substitutions described in aesub(5) are available. If you need a transaction ID, use the $version 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).

All of the substitutions described in aesub(5) are available. If you need a transaction ID, use the $version substitution.

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

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

${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.

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!

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

Please note that this field does not apply to the diff_command or merge_command fields.

${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).

Note: It is possible to configure a project to omit the diff step as unnecessary, by the following setting:

${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 success, all non‐zero exits indicate failure (the aed will fail).

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

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 "set +e; diff $option $original $input > $output; test $? -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 success, all non‐zero exits indicate failure (the aed will fail).

The exit status is examined. An zero exit status (success) means that the change will proceed to the awaiting integration state; a non‐zero exit status (failure) means that the change requires further review state, and the develop_end_action is consulted to determine the appropriate state (awaiting_review or being_reviewed) for the change to move to.

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

The exit status is examined. An zero exit status (success) means that the change may leave to the being developed state; a non‐zero exit status (failure) means that the change requires further development.

All of the substitutions described by aesub(5) are available.

Executed as: the developer. Current directory: the development directory. Exit status: zero indicates success, non‐zero indicates failure.

There are some common validations available in the aede‐policy(1) command; you may choose all or only some of them, or you may choose to write a policy command specific to your project.

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 being developed state).

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.

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.

${VARiables}

The text of name=value variable settings from the command line, suitably quoted to protect special character 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 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".

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.

${VARiables}

The text of name=value variable settings from the command line, suitably quoted to protect special character 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 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".

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.

${VARiables}

The text of name=value variable settings from the command line, suitably quoted to protect special character 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 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 -independent tests). Exit status: zero indicates success, one indicates failure, anything else indicates "no result".

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

architecture =
[
        {
                name = "unspecified";
                pattern = "*";
                mode = required;
        }
];

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 “*”).

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 “*”).

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.

The file name lengths of project files will be checked at develop end if the project aegis.conf file is in the change. See aede (1) for more information.

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 defaults to true if not set.

The white space characters (space, tab, newline, etc) are considered shell special characters.

Defaults to false if not set.

Note that this field does not override other file name filters. It will be necessary to explicitly set shell_safe_filenames = false as well. It will be necessary to set dos_filename_required = false (the default) as well. It will be necessary to set posix_filename_charset = false (the default) as well.

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

Defaults to false if not set.

Note that this field does not override other file name filters. It will be necessary to explicitly set shell_safe_filenames = false as well. It will be necessary to set dos_filename_required = false (the default) as well. It will be necessary to set posix_filename_charset = false (the default) as well.

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

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.

File_Name

The absolute path name of the source file.

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

name = string;

The name of the value. By convention, names which start with an upper‐case letter will appear in listings, 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 aede‐policy(1) command line.

ae‐repo‐ci:commit‐message

See ae‐repo‐ci(1) for more information.

aede‐policy

See aede‐policy(1) for more information.

aede‐policy:version‐info:library

See aede‐policy(1) for more information.

aeget:inventory:hide

See aeget(1) for more information.

aemakegen:debian:build‐depends

See aemakegen(1) for more information.

aemakegen:debian:copyright

See aemakegen(1) for more information.

aemakegen:debian:depends

See aemakegen(1) for more information.

aemakegen:debian:description:name

See aemakegen(1) for more information.

aemakegen:debian:extended‐description:name

See aemakegen(1) for more information.

aemakegen:debian:homepage

See aemakegen(1) for more information.

aemakegen:debian:maintainer

See aemakegen(1) for more information.

aemakegen:debian:priority

See aemakegen(1) for more information.

aemakegen:debian:section

See aemakegen(1) for more information.

aemakegen:pkg‐config:cflags

See aemakegen(1) for more information.

aemakegen:pkg‐config:conflicts

See aemakegen(1) for more information.

aemakegen:pkg‐config:libs

See aemakegen(1) for more information.

aemakegen:pkg‐config:libs.private

See aemakegen(1) for more information.

aemakegen:pkg‐config:requires

See aemakegen(1) for more information.

aemakegen:version‐info

See aemakegen(1) for more information.

aetar:exclude

This attribute is used by he aetar(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 ${copyright‐owner} substitution, and is the one checked by the aede‐policy(1) command. Only set this attribute if your project is a work‐for‐hire under copyright law. It defaults to the value of ${user name} if not set, this is almost always correct for Open Source projects.

html:body‐begin

This attribute is used by the aeget(1) command to customize generated web pages. See aeget(1) for more information.

html:meta

This attribute is used by the aeget(1) command to customize generated web pages. See aeget(1) for more information.

html:body‐end

This attribute is used by the aeget(1) command to customize generated web pages. See aeget(1) for more information.

svn:password

See ae‐repo‐ci for more information.

svn:username

See ae‐repo‐ci for more information.

When commands are executed by Aegis, it ensures that the AEGIS_PROJECT, AEGIS_CHANGE, AEGIS_ARCH, LINES and COLS environment variables are set appropriately. The project configuration file's project_specific field is also consulted, looking for value's whose name starts with "setenv:" and sets the corresponding environment variable. All of the substitutions described by aesub(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}";
  },
];

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 much productivity. You have been warned.

See also the build_time_adjust_notify_command field.

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/newsroom/press_releases/2004/2004_05_24_dco.html

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.

This field default to an empty list if not set.

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.

${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.

Defaults to false if not set.

Defaults to the same value as create_symlinks_before_build if not set.

Defaults to false if not set.

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.