aerevml(1)

NAME
aerevml - send and receive RevML change sets

SYNOPSIS
aerevml -Send [ option... ]
aerevml -Receive [ option... ]
aerevml -Help
aerevml -VERSion

DESCRIPTION
The aerevml command is used to send and receive change sets using the RevML format. This format is independent of any particular VC/SCM tool or vendor. It allows export from any RevML capable VC/SCM system and import into any other RevML capable VC/SCM system.

The basic function is to reproduce a change, so a command like
    aerevml -send | aerevml -receive
may be used to clone a change, though less efficiently than aeclone(1). The file format used is designed to withstand mail servers, so activities such as
    aerevml -send | e-mail | aerevml -receive
(where e-mail represents sending, transporting and receiving your e-mail) will reproduce the change on a remote system. With suitable tools (such as PGP) is it possible to
    aerevml -send | encrypt | e-mail | decrypt | aerevml -receive
The mechanism is also designed to allow web-based distribution such as
    aerevml -send | web-server → web-browser | aerevml -receive
by the use of appropriate CGI scripts and mailcap entries.

It is possible to support both a “push” model and a “pull” model using this command. For suggestions and ideas for various ways to do this, see the Aegis Users Guide.

  RevML Project
The RevML format is used for copying revision controlled files and change sets between various SCM repositories. The RevML project may be found at http://public.perforce.com/public/revml/index.html

The latest RevML DTD may be found at http://public.perforce.com/public/revml/revml.dtd

SEND
The send variant takes a specified change, or baseline, and constructs a distribution package containing all of the change attributes and source file attributes and source file contents. The result is compressed, and encoded into a text format which can be sent as e-mail without being corrupted by the mail transfer agents along the way.

  Options
The following options are understood by the send variant:

-BaseLine
    This option may be used to specify the source of a project, rather than a change. Implies the -Entire_Source option, unless over-ridden.

-Description_Header
    This option may be used to add an RFC 822 style header to the change description being sent, with a From and Date line. This is the default.

-No_Description_Header
    This option suppresses the description header.

-Entire_Source
    This option may be used to send the entire source of the project, as well as the change source files.

-Partial_Source
    This option may be used to send only source files of a change. This is the default, except for the -BaseLine option.

RECEIVE
The receive variant takes a change package created by the send variant and creates an Aegis change (see aenc(1)) to implement the change within. Files are added to the change (see aerm(1), aecp(1), aenf(1) and aent(1)) and then the file contents are unpackaged into the development directory.

The change is then built (see aeb(1)), differenced (see aed(1)), and tested (see aet(1)). If all of this is successful, development of the change is ended (see aed(1)). The automatic process stops at this point, so that a local reviewer can confirm that the change is desired.

  Notification
The aerevml command invokes various other Aegis commands. The usual notifications that these commands would issue are issued.

  Options
The following options are understood by the receive variant:

-Change number
    This option may be used to choose the change number to be used, otherwise one will be chosen automatically.

-DELta number
    This option may be used to specify a particular delta in the project's history to copy the file from, just as for the aecp(1) command. You may also use a delta name instead of a delta number.

-Ignore_UUID
    This option may be used to ignore the UUID, if present, of the incoming change set.

-No_Ignore_UUID
    This option force the aerevml command to use the change set's UUID. This is the default.

-Project name
    This option may be used to set the project name. If not specified, the project name in the input package will be used, rather than the usual project name defaulting mechanism.

  Security
Receiving changes by e-mail, and automatically committing them to the baseline without checking them, would be a recipe for disaster. A number of safeguards are provided:

•   The format of the package is confirmed to be correct, and the package verified for internal consistency, before it is unpacked and acted upon.

•   The automatic portion of the process stops when development ends. This ensures that a local reviewer validates the change before it is committed, preventing accidental or malicious damage.

•   If the change seeks to update the project config file, the automatic process terminates before the build or difference occurs. This is because this file could contain trojans for these operations, so a human must examine the file before the change proceeds any further.

•   There is a potential_trojan_horse = [ string ]; field in the projectconfig file. Nominate build configuration files, shell scripts, code generators, etc here to specify files in addition to the project configuration file which should cause the automatic processing to halt.

•   The use of e-mail authentication and encryption systems, such as PGP and GPG, are encouraged. However, it is expected that this processing will occur after aerevml --send has constructed the package and before aerevml --receive examines and acts on the package. Verification of the sender is the surest defense against trojan horses.

•   Automatic sending and receiving of packages is supported, but not implemented within the aerevml command. It is expected that the aerevml command will be used within shell scripts customized for your site and its unique security requirements. See the Aegis User Guide for several different ways to do this.

•   The more you use Aegis' test management facilities (see aent(1) and aet(1)) the harder it is for an inadequate change to get into the baseline.

  Duplicate Storms
In a distributed development environment, it is common for change sets to eventually be propagated back to the originator. There are situations (particularly in some star topologies) where several copies of the package will return to the originator.

If these change sets are not detected at the review stage, and are propagated out yet again, there is the possibility of an exponential explosion of redundant change sets being distributed again and again.

To combat this, changes are checked after the files are unpacked, but before and build or difference or test is performed. The “aecpu --unchanged” command is used to exclude all files that the local repository already has in the desired form. If no change files remain after this, the change is dropped entirely (see aedbu(1) and aencu(1)).

LIST
The list variant can be used to list the contents of a package without actually unpacking it first. The output is reminiscent of the aegis -list change-details output.

  Options
The following options are understood by the list variant: Only useful with the -List option.

OPTIONS
The following options to this command haven't been mentioned yet: