1
0
mirror of https://github.com/php/php-src.git synced 2026-04-11 18:13:00 +02:00

Aghh. Despite my efforts two files still slipped through

This commit is contained in:
Sam Liddicott
2001-01-18 13:30:02 +00:00
parent 04d7c9815f
commit fd46d9ee9e
2 changed files with 0 additions and 2859 deletions

File diff suppressed because it is too large Load Diff

View File

@@ -1,280 +0,0 @@
/*
* aegis - project change supervisor
* This file is in the Public Domain, 1995, 1998, 2000 Peter Miller.
*
* MANIFEST: example of using rcs in the project config file
*
* The entries for the commands are listed below. RCS uses a slightly
* different model than aegis wants, so some maneuvering is required.
* The command strings in this section assume that the RCS commands ci and co
* and rcs and rlog are in the command search PATH, but you may like to
* hard-wire the paths, or set PATH at the start of each. You should also note
* that the strings are always handed to the Bourne shell to be executed, and
* are set to exit with an error immediately a sub-command fails.
*
* In these commands, the RCS file is kept unlocked, since only the owner will
* be checking changes in. The RCS functionality for coordinating shared
* access is not required.
*
* One advantage of using RCS version 5.6 or later is that binary files are
* supported, should you want to have binary files in the baseline.
*
* The ${quote ...} construct is used to quote filenames which contain
* shell special characters. A minimum of quoting is performed, so if
* the filenames do not contain shell special characters, no quotes will
* be used.
*/
/*
* This command is used to create a new file history.
* This command is always executed as the project owner.
* The following substitutions are available:
*
* ${Input}
* absolute path of the source file
* ${History}
* absolute path of the history file
*
* The "ci -f" option is used to specify that a copy is to be checked-in even
* if there are no changes.
* The "ci -u" option is used to specify that an unlocked copy will remain in
* the baseline.
* The "ci -d" option is used to specify that the file time rather than the
* current time is to be used for the new revision.
* The "ci -M" option is used to specify that the mode date on the original
* file is not to be altered.
* The "ci -t" option is used to specify that there is to be no description
* text for the new RCS file.
* The "ci -m" option is used to specify that the change number is to be stored
* in the file log if this is actually an update (typically from aenf
* after aerm on the same file name).
* The "rcs -U" option is used to specify that the new RCS file is to have
* unstrict locking.
*/
history_create_command =
"ci -f -u -d -M -m$c -t/dev/null ${quote $input} ${quote $history,v}; \
rcs -U ${quote $history,v}";
/*
* This command is used to get a specific edit back from history.
* This command is always executed as the project owner.
* The following substitutions are available:
*
* ${History}
* absolute path of the history file
* ${Edit}
* edit number, as given by history_\%query_\%command
* ${Output}
* absolute path of the destination file
*
* The "co -r" option is used to specify the edit to be retrieved.
* The "co -p" option is used to specify that the results be printed on the
* standard output; this is because the destination filename will never
* look anything like the history source filename.
*/
history_get_command =
"co -r${quote $edit} -p ${quote $history,v} > ${quote $output}";
/*
* This command is used to add a new "top-most" entry to the history file.
* This command is always executed as the project owner.
* The following substitutions are available:
*
* ${Input}
* absolute path of source file
* ${History}
* absolute path of history file
*
* The "ci -f" option is used to specify that a copy is to be checked-in even
* if there are no changes.
* The "ci -u" option is used to specify that an unlocked copy will remain in
* the baseline.
* The "ci -d" option is used to specify that the file time rather than the
* current time is to be used for the new revision.
* The "ci -M" option is used to specify that the mode date on the original
* file is not to be altered.
* The "ci -m" option is used to specify that the change number is to be stored
* in the file log, which allows rlog to be used to find the change
* numbers to which each revision of the file corresponds.
*
* It is possible for a a very cautious approach has been taken, in which case
* the history_put_command may be set to the same string specified above for
* the history_create_command.
*/
history_put_command =
"ci -f -u -d -M -m$c ${quote $input} ${quote $history,v}";
/*
* This command is used to query what the history mechanism calls the top-most
* edit of a history file. The result may be any arbitrary string, it need not
* be anything like a number, just so long as it uniquely identifies the edit
* for use by the history_get_command at a later date. The edit number is to
* be printed on the standard output. This command is always executed as the
* project owner.
*
* The following substitutions are available:
*
* ${History}
* absolute path of the history file
*/
history_query_command =
"rlog -r ${quote $history,v} | awk '/^head:/ {print $$2}'";
/*
* RCS also provides a merge program, which can be used to provide a three-way
* merge. It has an output format some sites prefer to the fmerge output.
*
* This command is used by aed(1) to produce a difference listing when a file
* in the development directory is out of date compared to the current version
* in the baseline.
*
* All of the command substitutions described in aesub(5) are available.
* In addition, the following substitutions are also available:
*
* ${ORiginal}
* The absolute path name of a file containing the common ancestor
* version of ${MostRecent} and {$Input}. Usually the version originally
* copied into the change. Usually in a temporary file.
* ${Most_Recent}
* The absolute path name of a file containing the most recent version.
* Usually in the baseline.
* ${Input}
* The absolute path name of the edited version of the file. Usually in
* the development directory.
* ${Output}
* The absolute path name of the file in which to write the difference
* listing. Usually in the development directory.
*
* An exit status of 0 means successful, even of the files differ (and they
* usually do). An exit status which is non-zero means something is wrong.
*
* The "merge -L" options are used to specify labels for the baseline and the
* development directory, respectively, when conflict lines are inserted
* into the result.
* The "merge -p" options is used to specify that the results are to be printed
* on the standard output.
*/
merge_command =
"set +e; \
merge -p -L baseline -L C$c ${quote $mostrecent} ${quote $original} \
${quote $input} > ${quote $output}; \
test $? -le 1";
/*
* Many history tools (including 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.
*
* If you use RCS keyword substitution, you will need this next line.
* (The default is to report a fatal error.)
*/
history_put_trashes_file = warn;
/*
* aegis - project change supervisor
* This file is in the Public Domain, 1995, Peter Miller.
*
* MANIFEST: example use of cook in project config file
*
* The make(1) program exists in many forms, usually one is available with each
* UNIX version. The one used in the writing of this section is GNU Make 3.70,
* available by anonymous FTP from your nearest GNU archive site. GNU Make was
* chosen because it was the most powerful, it is widely available (usually for
* little or no cost) and discussion of the alternatives (SunOS make, BSD 4.3
* make, etc), would not be universally applicable. "Plain vanilla" make
* (with no transitive closure, no pattern rules, no functions) is not
* sufficiently capable to satisfy the demands placed on it by aegis.
*
* As mentioned in the Dependency Maintenance Tool chapter of the User Guide,
* make is not really sufficient, because it lacks dynamic include dependencies.
* However, GNU Make has a form of dynamic include dependencies, and it has a
* few quirks, but mostly works well.
*
* The other feature lacking in make is a search path. While GNU Make has
* functionality called VPATH, the implementation leaves something to be
* desired, and can't be used for the search path functionality required by
* aegis. Because of this, the create_symlinks_before_build field of the
* project config file is set to true so that aegis will arrange for the
* development directory to be full of symbolic links, making it appear that
* the entire project is in each change's development directory.
*/
/*
* The build_command field of the project config file is used to invoke the
* relevant build command. This command tells make where to find the rules.
* The ${s Makefile} expands to a path into the baseline during development
* if the file is not in the change. Look in aesub(5) for more information
* about command substitutions.
*/
build_command =
"make -f ${s Makefile.php} project=$p change=$c version=$v PHP=php-4.0.4";
/* "project=\"$p\" change=\"$c\" version=\"$v\" /bin/sh ./build";*/
/*
* The rules used in the User Guide all remove their targets before
* constructing them, which qualifies them for the following entry in the
* config file. The files must be removed first, otherwise the baseline would
* cease to be self-consistent.
*/
link_integration_directory = true;
/*
* Another field to be set in this file is one which tells aegis to maintain
* symbolic links between the development directory and the baseline. This also
* requires that rules remove their targets before constructing them, to ensure
* that development builds do not attempt to write their results onto the
* read-only versions in the baseline.
*/
create_symlinks_before_build = true;
/*
* aegis - project change supervisor
* This file is in the Public Domain, 1999 Peter Miller.
*
* MANIFEST: example use of diff in the project config file
*
* The ${quote ...} construct is used to quote filenames which contain
* shell special characters. A minimum of quoting is performed, so if
* the filenames do not contain shell special characters, no quotes will
* be used.
*/
/*
* Compare two files using GNU diff. The -U 10 option produces an output
* with inserts and deletes shown line, with 10 lines of context before
* and after. This is usually superior to -c, as it shows what happened
* more clearly (and it takes less space). The -b option could be added
* to compare runs of white space as equal.
*
* This command is used by aed(1) to produce a difference listing when
* file in the development directory was originally copied from the
* current version in the baseline.
*
* All of the command substitutions described in aesub(5) are available.
* In addition, the following substitutions are also available:
*
* ${ORiginal}
* The absolute path name of a file containing the version
* originally copied. Usually in the baseline.
* ${Input}
* The absolute path name of the edited version of the file.
* Usually in the development directory.
* ${Output}
* The absolute path name of the file in which to write the
* difference listing. Usually in the development directory.
*
* An exit status of 0 means successful, even of the files differ (and
* they usually do). An exit status which is non-zero means something
* is wrong. (So we need to massage the exit status, because diff does
* things a little differently.)
*
* The non-zero exit status may be used to overload this command with
* extra tests, such as line length limits. The difference files must
* be produced in addition to these extra tests.
*/
diff_command =
"set +e; diff -U10 ${quote $original} ${quote $input} > ${quote $output}; test $? -le 1";