@need 3200

@node A Very Brief Overview of arch
@chapter A Very Brief Overview of arch

If you understand @code{mkpatch} and @code{dopatch}, the rest of @code{arch} is
conceptually simple.


@code{arch} lets you build a library of revisions of a source tree.  


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


You can use the command @code{larch commit} to store your modified revision
in the archive.  @code{commit} compares your modifed revision to the
original using @code{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 @code{get} a revision, @code{arch} finds some "full
source" revision, then applies any patches necessary to get the
revision you asked for.  @code{arch} uses @code{dopatch} for that.


@code{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.


@code{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 @code{ChangeLog} many programmers
maintain by hand).  The patch log helps @code{arch} when it comes time to
merge: @code{arch} uses the log to decide which patches to apply, and which
to skip.




