The Hackerlab at `regexps.com`

## A Very Brief Overview of arch

up: arch

If you understand `mkpatch` and `dopatch` , the rest of `arch` is conceptually simple.

`arch` lets you build a library of revisions of a source tree.

You can use the command `larch get` to retrieve a particular revision, and then make changes to your local copy.

You can use the command `larch commit` to store your modified revision in the archive. `commit` compares your modifed revision to the original using `mkpatch` . It converts the patch set to a compressed tar file and installs that tar file in the archive (along with a log message).

In ordinary use, when you `get` a revision, `arch` finds some "full source" revision, then applies any patches necessary to get the revision you asked for. `arch` uses `dopatch` for that.

`arch` organizes revisions into "development paths" -- successive revisions, each one patch away from the previous.

You can form a "branches" -- places where one development path splits into two distinct paths.

You can perform various kinds of "merge" -- selectively applying various patches to bring your working copies up-to-date with respect to one or more development paths.

When multiple people share an archive, they use it as a "rendezvous point" -- a place and mechanism for sharing and coordinating patch sets.

`arch` "decorates" your source trees with some control files. The most important of these form the "patch log" -- a record of all of the patches that have been applied to your tree. The patch log helps users by forming a detailed record of the changes that have been made (similar to, but more accurate than, the `ChangeLog` many programmers maintain by hand). The patch log helps `arch` when it comes time to merge: `arch` uses the log to decide which patches to apply, and which to skip.

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