Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1556

News	FAQ
Search	Home

Subsections

• Synopsis
• Description
• Options
• Resources
• Notes
• Diagnostics
• Examples
• Bugs
• See also
• Author

exhale

Create AIPS++ source code updates.

Synopsis

exhale [-e] [-l]

Description

exhale generates updates for the AIPS++ code distribution system. It allows participating AIPS++ code development sites to maintain a slave RCS repository which tracks changes to the master (see inhale (p)).

exhale runs on the master AIPS++ host, aips2.nrao.edu, and is responsible for producing the following update files which is deposits in ~ftp/pub/master (see §1.1.5):

• The base release of the AIPS++ RCS version files (see avers (p)). These update files have names of the form master-mm.000.tar.gz, where mm is the two-digit major, or base-release version number. The base release files are produced infrequently, only by special request, and are preserved indefinitely.

• Incremental updates, each of which contains copies of all RCS version files which changed since the last time exhale ran. These have names of the form master-mm.nnn.tar.gz, where nnn is the three-digit minor, or incremental version number. They are kept for thirty days.

• The VERSION file is used as a timestamp file for the incremental updates. It also contains the major and minor version numbers of the most recent update and the time it was produced. The update is skipped if no files have been modified since the last incremental update.

• A cumulative update file which contains a copy of every RCS version file which has changed since the last base release. This has a name of the form master-mm.nnn.ALL.tar.gz. Cumulative update files are kept for seven days. In addition, cumulative update files are kept for all versions listed in the BLESSED file as having passed the testsuite (p) or having met whatever other criteria is deemed suitable.

  The base release file for the current major version is used as the timestamp for cumulative updates.

The update files are tar files which have been compressed by gzip for transmission to remote AIPS++ sites via ftp.

exhale also maintains a MANIFEST of all files distributed in each incremental update, a LOGFILE of every invokation, and a CHKSUM file used by inhale (p) for verification of received files.

exhale has many bookkeeping tasks to perform on the infrequent occasions when it is called upon to produce a new base release, mm.000 (see avers (p)):

• Make temporary copies of the master and archive on which to operate.

• Apply ax_master in ``archive'' mode (see ax (p)) to rescind or rename archive files and directories.

• Create any new directories in the archive that appeared in the master during AIPS++ major version ll, where ll = mm - 1.

• Delete rescinded files corresponding to AIPS++ major version kk from the master, where kk = mm - 2. These will have been archived when the base release for version ll was produced.

• Perform the following operations on every RCS version file in the master repository:
  • ``Outdate'' RCS revisions corresponding to AIPS++ major version kk using the rcs -o command, and also delete any symbolic names corresponding to the outdated revisions (these older revisions will have been archived when the base release for version ll was produced). The old revisions are deleted in order to reduce the size of the RCS version file for efficient checkin (ai (p)) and checkout (ao (p)). This operation is only performed when exhale is invoked with the -e option.

  • ``Uprev'' the RCS version file to RCS revision number m.0, subsequent revisions are numbered from that point. In this process, any exant locks are carried forward from RCS revision number l.? to m.0. Revision m.0, which contains no differences from the previous revision, is forcibly created using the ci -f command.

  • Concatenate RCS revisions numbered l.0 to m.0 in the master into the archive RCS version file using a specially written utility called rcscat (p). This includes rescinded files. Files created in the master since the previous base release are simply copied to the archive.

• Verify the master and archive using xrcs (p).

• Create the base release tar file for consortium installations in /pub/master.

• Create the base release tar files for end-user installations in /pub/code.

Options

-e

Expire mode; ``outdates'' old RCS revisions. Only useful when exhale is creating a new base release; ignored otherwise.

-l

Latchkey mode (see notes); the update produced will be invisible to inhale (p) unless it is also invoked with the -l option.

Resources

exhale always ignores $HOME/.aipsrc (see getrc (p)).

• account.manager: Account name (and group) of the owner of the AIPS++ source code. exhale only allows itself to be run from this account.

• account.programmer: (Account name and) name of the AIPS++ programmer group.

Notes

• Latchkey updates are used to restrict the AIPS++ distribution temporarily, for example, when the AIPS++ sources are undergoing significant structural changes which may take several days to complete. Instead of switching exhale off during this period, it may continue to be run in latchkey mode. The latchkey mechanism hides updates from general view, but slave installations which do want to track the changes may do so by specifying the -l latchkey option to inhale (p). Latchkey mode is terminated as soon as exhale is invoked without the -l option, even if there are no files to be updated.

  The latchkey mechanism works by recording a version and timestamp on the second line of the VERSION file. Normally inhale (p) obtains the current version number from the first line, but if invoked with the -l option it reads the last line instead.

• exhale should only to be run from the machine which holds the master copy of AIPS++ source code in Socorro.

• exhale disables checkins (ai (p)), checkouts (ao (p)), header changes (am (p)), deletions (ax (p)), and renames (amv (p)) for the duration of its execution.

• A new base release is signalled by manually incrementing the major version number in ~ftp/pub/master/VERSION and setting the minor version number to ``-''.

• exhale regenerates the av (p) filename cache, consolidating all addenda into a single cache file.

Diagnostics

Status return values correspond to the various phases of the operation
0: success
1: initialization error
2: error preparing a new base release
3: error creating incremental or base update
4: error creating cumulative update
5: error creating public release
6: installation error

Examples

The following aips2mgr cron entry runs exhale at 0630 and 1830 each night in Socorro.

   30 06,18 * * * (. $HOME/.profile ; exhale)

Bugs

• The $AIPSMSTR and /pub directory hierarchies must reside in the same unix filesystem.

• Newly created directories are not propagated if they don't contain newly created files.

• exhale does most of its work in temporary directories beneath /pub/master and /pub/code, and cleans up on receiving a catchable interrupt. However, sending it a SIGKILL signal (e.g. via kill -9) would at the least cause it not to clean up its work directories, but if given during the brief though crucial installation phase, could cause serious damage to the integrity of the code distribution system.

See also

The unix manual page for cron(1).
The unix manual page for ftp(1).
The unix manual page for tar(1).
The GNU manual page for gzip(1).
Section §1.4, AIPS++ accounts and groups.
AIPS++ variable names (§1.2).
avers (p), AIPS++ version report utility.
ax (p), AIPS++ code deletion utility.
getrc (p), query AIPS++ resource database.
inhale (p), AIPS++ code import utility.
av (p), AIPS++ filename validation utility.
rcscat (p), concatenate two RCS version files.
testsuite (p), maintain the most recent good cumulative update.
xrcs (p), verify the internal consistency of RCS version files.

Author

Original: 1992/04/06 by Mark Calabretta, ATNF.