config

   1
   2 /*
   3  * The build_command field of the project config file is used to invoke the
   4  * relevant build command.  This command tells make where to find the rules.
   5  * The ${s Makefile} expands to a path into the baseline during development
   6  * if the file is not in the change.  Look in aesub(5) for more information
   7  * about command substitutions.
   8  */
   9 build_command =
  10         "gmake -f ${s Makefile} project=$p change=$c version=$v";
  11
  12 /*
  13  * The rules used in the User Guide all remove their targets before
  14  * constructing them, which qualifies them for the following entry in the
  15  * config file.  The files must be removed first, otherwise the baseline would
  16  * cease to be self-consistent.
  17  */
  18 link_integration_directory = true;
  19
  20 /*
  21  * Another field to be set in this file is one which tells aegis to maintain
  22  * symbolic links between the development directory and the baseline.  This also
  23  * requires that rules remove their targets before constructing them, to ensure
  24  * that development builds do not attempt to write their results onto the
  25  * read-only versions in the baseline.
  26  */
  27 create_symlinks_before_build = true;
  28
  29
  30 /*
  31  * Compare two files using GNU diff.  The -U 10 option produces an output
  32  * with inserts and deletes shown line, with 10 lines of context before
  33  * and after.  This is usually superior to -c, as it shows what happened
  34  * more clearly (and it takes less space).  The -b option could be added
  35  * to compare runs of white space as equal.
  36  *
  37  * This command is used by aed(1) to produce a difference listing when
  38  * file in the development directory was originally copied from the
  39  * current version in the baseline.
  40  *
  41  * All of the command substitutions described in aesub(5) are available.
  42  * In addition, the following substitutions are also available:
  43  *
  44  * ${ORiginal}
  45  *      The absolute path name of a file containing the version
  46  *      originally copied.  Usually in the baseline.
  47  * ${Input}
  48  *      The absolute path name of the edited version of the file.
  49  *      Usually in the development directory.
  50  * ${Output}
  51  *      The absolute path name of the file in which to write the
  52  *      difference listing.  Usually in the development directory.
  53  *
  54  * An exit status of 0 means successful, even of the files differ (and
  55  * they usually do).  An exit status which is non-zero means something
  56  * is wrong.  (So we need to massage the exit status, because diff does
  57  * things a little differently.)
  58  *
  59  * The non-zero exit status may be used to overload this command with
  60  * extra tests, such as line length limits.  The difference files must
  61  * be produced in addition to these extra tests.
  62  */
  63 diff_command =
  64         "set +e; "
  65         "diff -U10 -a ${quote $original} ${quote $input} > ${quote $output}; "
  66         "test $? -le 1";
  67
  68
  69 /*
  70  * The entries for the commands are listed below.  RCS uses a slightly
  71  * different model than aegis wants, so some maneuvering is required.
  72  * The command strings in this section assume that the RCS commands ci and co
  73  * and rcs and rlog are in the command search PATH, but you may like to
  74  * hard-wire the paths, or set PATH at the start of each.  You should also note
  75  * that the strings are always handed to the Bourne shell to be executed, and
  76  * are set to exit with an error immediately a sub-command fails.
  77  *
  78  * In these commands, the RCS file is kept unlocked, since only the owner will
  79  * be checking changes in.  The RCS functionality for coordinating shared
  80  * access is not required.
  81  *
  82  * One advantage of using RCS version 5.6 or later is that binary files are
  83  * supported, should you want to have binary files in the baseline.
  84  *
  85  * The ${quote ...} construct is used to quote filenames which contain
  86  * shell special characters.  A minimum of quoting is performed, so if
  87  * the filenames do not contain shell special characters, no quotes will
  88  * be used.
  89  */
  90
  91 /*
  92  * This command is used to create a new file history.
  93  * This command is always executed as the project owner.
  94  * The following substitutions are available:
  95  *
  96  * ${Input}
  97  *      absolute path of the source file
  98  * ${History}
  99  *      absolute path of the history file
 100  *
 101  * The "ci -u" option is used to specify that an unlocked copy will remain in
 102  *      the baseline.
 103  * The "ci -d" option is used to specify that the file time rather than the
 104  *      current time is to be used for the new revision.
 105  * The "ci -M" option is used to specify that the mode date on the original
 106  *      file is not to be altered.
 107  * The "ci -t" option is used to specify that there is to be no description
 108  *      text for the new RCS file.
 109  * The "ci -m" option is used to specify that the change number is to be stored
 110  *      in the file log if this is actually an update (typically from aenf
 111  *      after aerm on the same file name).
 112  * The "ci -w" option is used to specify the user name at checkin,
 113  *      since this is always run by the project owner, and we almost
 114  *      always want to know the developer.
 115  * The "rcs -U" option is used to specify that the new RCS file is to have
 116  *      unstrict locking.
 117  *
 118  * It is essential that the history_put_command be identical to the
 119  * the history_create_command for branching to work correctly.
 120  */
 121 history_create_command =
 122         "ci -u -d -M -m${quote ($version) ${change description}} \
 123 -w$developer \
 124 -t/dev/null ${quote $input} ${quote $history,v}; \
 125 rcs -U ${quote $history,v}";
 126
 127
 128 /*
 129  * This command is used to get a specific edit back from history.
 130  * This command is always executed as the project owner.
 131  * The following substitutions are available:
 132  *
 133  * ${History}
 134  *      absolute path of the history file
 135  * ${Edit}
 136  *      edit number, as given by history_\%query_\%command
 137  * ${Output}
 138  *      absolute path of the destination file
 139  *
 140  * The "co -r" option is used to specify the edit to be retrieved.
 141  * The "co -p" option is used to specify that the results be printed on the
 142  *      standard output; this is because the destination filename will never
 143  *      look anything like the history source filename.
 144  */
 145 history_get_command =
 146         "co -r${quote $edit} -p ${quote $history,v} > ${quote $output}";
 147
 148 /*
 149  * This command is used to add a new "top-most" entry to the history file.
 150  * This command is always executed as the project owner.
 151  * The following substitutions are available:
 152  *
 153  * ${Input}
 154  *      absolute path of source file
 155  * ${History}
 156  *      absolute path of history file
 157  *
 158  * The "ci -f" option is used to specify that a copy is to be checked-in even
 159  *      if there are no changes.
 160  * The "ci -u" option is used to specify that an unlocked copy will remain in
 161  *      the baseline.
 162  * The "ci -d" option is used to specify that the file time rather than the
 163  *      current time is to be used for the new revision.
 164  * The "ci -M" option is used to specify that the mode date on the original
 165  *      file is not to be altered.
 166  * The "ci -m" option is used to specify that the change number is to be stored
 167  *      in the file log, which allows rlog to be used to find the change
 168  *      numbers to which each revision of the file corresponds.
 169  * The "ci -w" option is used to specify the user name at checkin,
 170  *      since this is always run by the project owner, and we almost
 171  *      always want to know the developer.
 172  *
 173  * It is essential that the history_put_command be identical to the
 174  * the history_create_command for branching to work correctly.
 175  */
 176 history_put_command =
 177         "ci -u -d -M -m${quote ($version) ${change description}} \
 178 -w$developer \
 179 -t/dev/null ${quote $input} ${quote $history,v}; \
 180 rcs -U ${quote $history,v}";
 181
 182 /*
 183  * This command is used to query what the history mechanism calls the top-most
 184  * edit of a history file.  The result may be any arbitrary string, it need not
 185  * be anything like a number, just so long as it uniquely identifies the edit
 186  * for use by the history_get_command at a later date.  The edit number is to
 187  * be printed on the standard output.  This command is always executed as the
 188  * project owner.
 189  *
 190  * The following substitutions are available:
 191  *
 192  * ${History}
 193  *      absolute path of the history file
 194  */
 195 history_query_command =
 196         "rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";
 197
 198 /*
 199  * RCS also provides a merge program, which can be used to provide a three-way
 200  * merge.  It has an output format some sites prefer to the fmerge output.
 201  *
 202  * This command is used by aed(1) to produce a difference listing when a file
 203  * in the development directory is out of date compared to the current version
 204  * in the baseline.
 205  *
 206  * All of the command substitutions described in aesub(5) are available.
 207  * In addition, the following substitutions are also available:
 208  *
 209  * ${ORiginal}
 210  *      The absolute path name of a file containing the common ancestor
 211  *      version of ${MostRecent} and {$Input}.  Usually the version originally
 212  *      copied into the change.  Usually in a temporary file.
 213  * ${Most_Recent}
 214  *      The absolute path name of a file containing the most recent version.
 215  *      Usually in the baseline.
 216  * ${Input}
 217  *      The absolute path name of the edited version of the file.  Usually in
 218  *      the development directory.
 219  * ${Output}
 220  *      The absolute path name of the file in which to write the difference
 221  *      listing.  Usually in the development directory.
 222  *
 223  * An exit status of 0 means successful, even of the files differ (and they
 224  * usually do).  An exit status which is non-zero means something is wrong.
 225  *
 226  * The "merge -L" options are used to specify labels for the baseline and the
 227  *      development directory, respectively, when conflict lines are inserted
 228  *      into the result.
 229  * The "merge -p" options is used to specify that the results are to be printed
 230  *      on the standard output.
 231  */
 232
 233 merge_command =
 234         "set +e; \
 235 merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
 236 ${quote $input} > ${quote $output}; \
 237 test $? -le 1";
 238
 239 /*
 240  * Many history tools (including RCS) can modify the contents of the file
 241  * when it is committed.  While there are usually options to turn this
 242  * off, they are seldom used.  The problem is: if the commit changes the
 243  * file, the source in the repository now no longer matches the object
 244  * file in the repository - i.e. the history tool has compromised the
 245  * referential integrity of the repository.
 246  *
 247  * If you use RCS keyword substitution, you will need this next line.
 248  * (The default is to report a fatal error.)
 249  */
 250 history_put_trashes_file = warn;