The Hackerlab at `regexps.com`

## Multi-tree Projects and Configuration Management

up: arch

You can define meta-projects which are combinations of individual projects that are separately tracked by `arch` . This allows you to divide a large project into smaller, more managable pieces, each of which can develop independently of the others, and each of which can be a part of more than one meta-project.

This is accomplished by writing config specs , which define the contents of the meta-project and how they should be arranged in a source tree.

For example, `arch` itself is a meta-project. The source tree contains:

            dists/
              dists/src/
                dists/src/arch/
                dists/src/file-utils/
                dists/src/ftp-utils/
                dists/src/hackerlab/
                dists/src/shell-utils/

Each of those directories is the root of a project tree (contains a subdirectory named {arch} ).

The top most directory, `dists` also contains a subdirectory named `configs` . In that subdirectory are the metaproject configuration files. For example:

            dists/
              dists/configs/
                dists/configs/regexps.com/  # Tom's configuration files
                  dists/configs/regexps.com/devo.arch
                  dists/configs/regexps.com/release-template.arch

Here are the contents of `devo.arch` :

         #
         # Check out an arch distribution from the devo branches.
         # Latest revisions.
         #

         ./src                   lord@regexps.com--2002/package-framework--devo
         ./src/arch              lord@regexps.com--2002/arch--devo
         ./src/file-utils        lord@regexps.com--2002/file-utils--devo
         ./src/ftp-utils         lord@regexps.com--2002/ftp-utils--devo
         ./src/hackerlab         lord@regexps.com--2002/hackerlab--devo
         ./src/shell-utils       lord@regexps.com--2002/shell-utils--devo
         ./src/text-utils        lord@regexps.com--2002/text-utils--devo

Each (non-blank, non-comment) line in that file has the format:

            LOCATION             CONTENTS

which means, to create the meta-project, get the revision indicated by `CONTENTS` and install it at `LOCATION` . The `CONTENTS` field can be a branch (meaning, get the latest revision of the latest version on that branch), a version (meaning get the latest revision in that version), or a revision name (meaning get that revision, exactly).

To check out an entire `arch` tree, I first check out `dists` from `devo` , then use `build-config` :

            % larch get dists--devo dists
            [....]

            % cd dists

            % larch build-config regexps.com/dists.devo
            [....]

Once you have a meta-project tree, some other useful commands are:

                   update-config : update a multi-project tree
                   replay-config : replay a multi-project tree

Those commands recursively `update` or `replay` the sub-trees in a meta-project.

One more configuration management command:

            % larch record-config GENERAL-CONFIG SPECIFIC-CONFIG

That reads a config file, the `GENERAL-CONFIG` . It examines the project tree to see what revisions are actually installed at each of the `LOCATIONs` . Then it writes a new config file, the `SPECIFIC-CONFIG` that has `CONTENTS` which specify those `REVISIONS` precisely. This is useful, for example, for recording the specific revisions you are about to turn into a distribution.

arch: The arch Revision Control System
The Hackerlab at `regexps.com`