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