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.
10 "gmake -f ${s Makefile} project=$p change=$c version=$v";
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.
18 link_integration_directory = true;
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.
27 create_symlinks_before_build = true;
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.
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.
41 * All of the command substitutions described in aesub(5) are available.
42 * In addition, the following substitutions are also available:
45 * The absolute path name of a file containing the version
46 * originally copied. Usually in the baseline.
48 * The absolute path name of the edited version of the file.
49 * Usually in the development directory.
51 * The absolute path name of the file in which to write the
52 * difference listing. Usually in the development directory.
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.)
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.
65 "diff -U10 -a ${quote $original} ${quote $input} > ${quote $output}; "
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.
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.
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.
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
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:
97 * absolute path of the source file
99 * absolute path of the history file
101 * The "ci -u" option is used to specify that an unlocked copy will remain in
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
118 * It is essential that the history_put_command be identical to the
119 * the history_create_command for branching to work correctly.
121 history_create_command =
122 "ci -u -d -M -m${quote ($version) ${change description}} \
124 -t/dev/null ${quote $input} ${quote $history,v}; \
125 rcs -U ${quote $history,v}";
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:
134 * absolute path of the history file
136 * edit number, as given by history_\%query_\%command
138 * absolute path of the destination file
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.
145 history_get_command =
146 "co -r${quote $edit} -p ${quote $history,v} > ${quote $output}";
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:
154 * absolute path of source file
156 * absolute path of history file
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
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.
173 * It is essential that the history_put_command be identical to the
174 * the history_create_command for branching to work correctly.
176 history_put_command =
177 "ci -u -d -M -m${quote ($version) ${change description}} \
179 -t/dev/null ${quote $input} ${quote $history,v}; \
180 rcs -U ${quote $history,v}";
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
190 * The following substitutions are available:
193 * absolute path of the history file
195 history_query_command =
196 "rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";
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.
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
206 * All of the command substitutions described in aesub(5) are available.
207 * In addition, the following substitutions are also available:
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.
214 * The absolute path name of a file containing the most recent version.
215 * Usually in the baseline.
217 * The absolute path name of the edited version of the file. Usually in
218 * the development directory.
220 * The absolute path name of the file in which to write the difference
221 * listing. Usually in the development directory.
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.
226 * The "merge -L" options are used to specify labels for the baseline and the
227 * development directory, respectively, when conflict lines are inserted
229 * The "merge -p" options is used to specify that the results are to be printed
230 * on the standard output.
235 merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
236 ${quote $input} > ${quote $output}; \
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.
247 * If you use RCS keyword substitution, you will need this next line.
248 * (The default is to report a fatal error.)
250 history_put_trashes_file = warn;