This is ../../monotone-1.0-branch/doc/monotone.info, produced by
makeinfo version 4.13 from ../../monotone-1.0-branch/doc/monotone.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* monotone: (monotone).         Monotone version control system
END-INFO-DIR-ENTRY


File: monotone.info,  Node: Top,  Next: Concepts,  Prev: (dir),  Up: (dir)

Overview
********

Monotone is a distributed version control tool. It can help automate
many tedious and error-prone tasks in group software development.
   * Store multiple versions of files you are working on efficiently.

   * Transmit changes to files between you and your colleagues.

   * Merge changes you make with those your colleagues make.

   * Make notes about your opinion of the quality of versions of files.

   * Make decisions about using or ignoring versions, depending on the
     notes you receive from others.

   Please be aware that monotone is a slightly unorthodox version
control tool, and many of its concepts are similar -- but subtly or
significantly different -- from concepts with similar names in other
version control tools.

* Menu:

* Concepts::                    Taxonomy of monotone
* Tutorial::                    A detailed example of using monotone
* Advanced Uses::               Going beyond the basics
* Command Reference::           Details of each monotone command
* Formats::                     Formats used by monotone and scripts
* Lua Reference::               How Lua is integrated in monotone
* Special Topics::              Extra explanations and details
* Default hooks::               The standard hook definitions
* General Index::               Index of concepts and functions

   Complete table of contents


File: monotone.info,  Node: Concepts,  Next: Tutorial,  Prev: Top,  Up: Top

1 Concepts
**********

This chapter should familiarize you with the concepts, terminology, and
behavior described in the remainder of the user manual.  Please take a
moment to read it, as later sections will assume familiarity with these
terms.

* Menu:

* Versions of files::           Tracking changes to single files
* Versions of trees::           Tracking changes to collections of files
* Historical records::          Tracking the history of changes
* Certificates::                Tracking extended information
* Storage and workflow::        Saving, sending, and receiving changes
* Forks and merges::            Managing divergence of code
* Branches::                    Intentional divergence and automatic merging


File: monotone.info,  Node: Versions of files,  Next: Versions of trees,  Prev: Concepts,  Up: Concepts

1.1 Versions of files
=====================

Suppose you wish to modify a file `file.txt' on your computer. You
begin with one version of the file, load it into an editor, make some
changes, and save the file again. Doing so produces a new version of
the file. We will say that the older version of the file was a
"parent", and the new version is a "child", and that you have performed
an "edit" between the parent and the child. We may draw the
relationship between parent and child using a graph, where the arrow in
the graph indicates the direction of the edit, from parent to child.

          +----------------+
          |                |
          | parent version |
          | of file.txt    |
          |                |
          +----------------+
                   |
                   |
                  \|/
                   V
          +----------------+
          |                |
          | child version  |
          | of file.txt    |
          |                |
          +----------------+

   We may want to identify the parent and the child precisely, for sake
of reference. To do so, we will compute a cryptographic hash function,
called SHA1, of each version. The details of this function are beyond
the scope of this document; in summary, the SHA1 function takes a
version of a file and produces a short string of 20 bytes, which we
will use to uniquely identify the version(1).  Now our graph does not
refer to some "abstract" parent and child, but rather to the exact edit
we performed between a specific parent and a specific child.

          +---------------------------------------------------+
          | parent version                                    |
          | of file.txt                                       |
          |                                                   |
          | SHA1 = 65f1bde1f38262034e7c3457301e8f736ba6381b   |
          +---------------------------------------------------+
                   |
                   |
                  \|/
                   V
          +---------------------------------------------------+
          | child version                                     |
          | of file.txt                                       |
          |                                                   |
          | SHA1 = a91566316d208dc405795904f8d67ae3a0e765cb   |
          +---------------------------------------------------+

   When dealing with versions of files, we will dispense with writing
out "file names", and identify versions purely by their SHA1 value,
which we will also refer to as their "file ID". Using IDs alone will
often help us accommodate the fact that people often wish to call files
by different names. So now our graph of parent and child is just a
relationship between two versions, only identified by ID.

          +---------------------------------------------------+
          | parent version                                    |
          | SHA1 = 65f1bde1f38262034e7c3457301e8f736ba6381b   |
          +---------------------------------------------------+
                   |
                   |
                  \|/
                   V
          +---------------------------------------------------+
          | child version                                     |
          | SHA1 = a91566316d208dc405795904f8d67ae3a0e765cb   |
          +---------------------------------------------------+

   Version control systems, such as monotone, are principally concerned
with the storage and management of multiple versions of some files.
One way to store multiple versions of a file is, literally, to save a
separate complete copy of the file, every time you make a change. When
necessary, monotone will save complete copies of your files, compressed
with the `zlib' compression format.

        +--------------+  +--------------+  +--------------+
        |              |  |              |  |              |
        | Hello        |  | Hello,       |  | Why, Hello   |
        |              |  | world!       |  | there world, |    . . .
        |              |  |              |  | how do you   |
        |              |  |              |  | do?          |
        |              |  |              |  |              |
        +--------------+  +--------------+  +--------------+

        \______  ______/  \______  ______/  \______  ______/
               \/                \/                \/
           1st version       2nd version      3rd version

   Often we find that successive versions of a file are very similar to
one another, so storing multiple complete copies is a waste of space.
In these cases, rather than store complete copies of each version of a
file, we store a compact description of only the changes which are made
between versions. Such a description of changes is called a "delta".

   Storing deltas between files is, practically speaking, as good as
storing complete versions of files. It lets you undo changes from a new
version, by applying the delta backwards, and lets your friends change
their old version of the file into the new version, by applying the
delta forwards. Deltas are usually smaller than full files, so when
possible monotone stores deltas, using a modified `xdelta' format. The
details of this format are beyond the scope of this document.

                             difference
                          between versions
                            _____/\____
        +--------------+   /           \    +--------------+
        |              |                    |              |
        | Hello        |    +[, world!]     | Hello,       |
        |              |                    | world!       |
        |              |                    |              |
        |              |                    |              |
        |              |                    |              |
        +--------------+                    +--------------+

        \______  ______/                    \______  ______/
               \/                                  \/
          1st version                         2nd version

   ---------- Footnotes ----------

   (1) We say SHA1 values are "unique" here, when in fact there is a
small probability of two different versions having the same SHA1 value.
This probability is very small, so we discount it.


File: monotone.info,  Node: Versions of trees,  Next: Historical records,  Prev: Versions of files,  Up: Concepts

1.2 Versions of trees
=====================

After you have made many different files, you may wish to capture a
"snapshot" of the versions of all the files in a particular collection.
Since files are typically collected into trees in a file system, we say
that you want to capture a version of your tree. Doing so will permit
you to undo changes to multiple files at once, or send your friend a
set of changes to many files at once.

   To make a snapshot of a tree, we begin by writing a special file
called a "manifest". In fact, monotone will write this file for us, but
we could write it ourselves too. It is just a plain text file, in a
structured but human-readable format used by several parts of monotone.
Each file entry of a manifest binds a specific name, as a full path from
the root of the workspace, to a specific file ID, as the hash of its
content.  In this way, the manifest collects together the snapshot of
the file names and contents you have at this point in time; other
snapshots with other manifests can use different names for the same
file, or different contents for the same name.

   Other entries in the manifest format name directories or store file
attributes, which we will cover later.


     +------------------------------------------------------+
     |                                                      |
     |  format_version "1"                                  |
     |                                                      |
     |  dir ""                                              |
     |                                                      |
     |  dir "fs"                                            |
     |                                                      |
     |     file "fs/readdir.c"                              |
     |  content [f2e5719b975e319c2371c98ed2c7231313fac9b5]  |
     |                                                      |
     |     file "fs/read_write.c"                           |
     |  content [81f0c9a0df254bc8d51bb785713a9f6d0b020b22]  |
     |                                                      |
     |     file "fs/pipe.c"                                 |
     |  content [943851e7da46014cb07473b90d55dd5145f24de0]  |
     |                                                      |
     |     file "fs/inode.c"                                |
     |  content [8ddcfcc568f33db6205316d072825d2e5c123275]  |
     |                                                      |
     +------------------------------------------------------+

     \_________________________  ___________________________/
                               \/
                           an example
                          manifest file

   Now we note that a manifest is itself a file. Therefore a manifest
can serve as input to the SHA1 function, and thus every manifest has an
ID of its own. By calculating the SHA1 value of a manifest, we capture
the state of our tree in a single "manifest ID". In other words, the ID
of the manifest essentially captures all the IDs and file names of
every file in our tree, combined. So we may treat manifests and their
IDs as snapshots of a tree of files, though lacking the actual contents
of the files themselves.

                         +--------------------------+
                         |   int readdir(...) {     |
                         |     ...                  |
                         |   }                      |
                         +--------------------------+

                         \____________  ____________/
                                      \/
                                     SHA1
                                      ||
     +--------------------------------||--------------------+
     |                       . . .    ||                    |
     |                                ||                    |
     |     file "fs/readdir.c"        \/                    |
     |  content [f2e5719b975e319c2371c98ed2c7231313fac9b5]  |
     |                                                      |
     |                       . . .
     +------------------------------------------------------+

     \_________________________  ___________________________/
                               \/
                              SHA1
                               ||
                               ||
                               \/
                          manifest ID:
            a2eeaa28574141a7d48fa1cc2802070150b93ec4

   As with versions of files, we may decide to store manifests in their
entirety, or else we may store only a compact description of changes
which occur between different versions of manifests. As with files,
when possible monotone stores compact descriptions of changes between
manifests; when necessary it stores complete versions of manifests.


File: monotone.info,  Node: Historical records,  Next: Certificates,  Prev: Versions of trees,  Up: Concepts

1.3 Historical records
======================

Suppose you sit down to edit some files. Before you start working, you
may record a manifest of the files, for reference sake. When you finish
working, you may record another manifest. These "before and after"
snapshots of the tree of files you worked on can serve as historical
records of the set of changes, or "changeset", that you made. In order
to capture a "complete" view of history - both the changes made and the
state of your file tree on either side of those changes - monotone
builds a special composite file called a "revision" each time you make
changes. Like manifests, revisions are ordinary text files which can be
passed through the SHA1 function and thus assigned a "revision ID".

     +-----------------------------------------------------------+
     |                                                           |
     |  format_version "1"                                       |
     |                                                           |
     |  new_manifest [83bc0a52da351cac950ac1c12d85be494fc21199]  |
     |                                                           |
     |  old_revision [75c9ffcab50c46e77e642751314b34a16fba36ff]  |
     |                                                           |
     |  add_file "include/foo.h"                                 |
     |   content [8ca6a9862bdeddfdb4b12248c075fa9570f45f6d]      |
     |                                                           |
     |  patch "include/bar.h"                                    |
     |   from [d624672a03e42d2172e56c4d54924af10ff8518d]         |
     |     to [2f58cfc4791aa1695b76c31c9cd1139b3d79ee1b]         |
     |                                                           |
     +-----------------------------------------------------------+

     \____________________________  _____________________________/
                                  \/
                                 SHA1
                                  ||
                                  \/
                             revision ID:
               1c83997e7ab40c0df47554c81b7d4e7ee691eb0d

   The content of a revision includes one or more changesets.  These
changesets make reference to file IDs, to describe how the tree changed.
The revision also contains manifest IDs, as another way of describing
the tree "before and after" the changeset -- storing this information
in two forms allows monotone to detect any bugs or corrupted data before
they can enter your history.  Finally and crucially, revisions also make
reference to other revision IDs. This fact - that revisions include the
IDs of other revisions - causes the set of revisions to join together
into a historical chain of events, somewhat like a "linked list".  Each
revision in the chain has a unique ID, which includes by reference all
the revisions preceding it. Even if you undo a changeset, and return to
a previously-visited manifest ID during the course of your edits, each
revision will incorporate the ID of its predecessor, thus forming a new
unique ID for each point in history.

     +-----------------------------------------------------------+
     |                                                           |
     |  format_version "1"                                       |
     |                                                           |
     |  new_manifest [dbd022dc423fd7f473e0fa79842cd9901cc2dd69] <-- manifest id
     |                                                           |
     |  old_revision: []                                         |
     |                                                           |
     |  ...                                                      |
     |                                                           |
     +-----------------------------------------------------------+

     \____________________________________  _____________________/
                                          \/
                                         SHA1
                                          ||
     +------------------------------------||---------------------+
     |                                    ||                     |
     |  format_version "1"                ||                     |
     |                                    ||                     |
     |  new_manifest [8a05c60422770bbf49a3||2c2367ddaa066538ca] <-- manifest id
     |                                    \/                     |
     |  old_revision [f45add3bfb21cb459d99b6a9c0111df75f6d9f85]  |
     |                                                           |
     |  ...                                                      |
     |                                                           |
     +-----------------------------------------------------------+

     \____________________________________  _____________________/
                                          \/
                                         SHA1
                                          ||
     +------------------------------------||---------------------+
     |                                    ||                     |
     |  format_version "1"                ||                     |
     |                                    ||                     |
     |  new_manifest [2027b4ab2febf98bd9a0||c000a69a8227cdaaf7] <-- manifest id
     |                                    \/                     |
     |  old_revision [1c83997e7ab40c0df47554c81b7d4e7ee691eb0d]  |
     |                                                           |
     |  ...                                                      |
     |                                                           |
     +-----------------------------------------------------------+

     \____________________________  _____________________________/
                                  \/
                                 SHA1
                                  ||
                                  \/
                             revision ID:
               1c83997e7ab40c0df47554c81b7d4e7ee691eb0d


File: monotone.info,  Node: Certificates,  Next: Storage and workflow,  Prev: Historical records,  Up: Concepts

1.4 Certificates
================

Often, you will wish to make a statement about a revision, such as
stating the reason that you made some changes, or stating the time at
which you made the changes, or stating that the revision passes a test
suite. Statements such as these can be thought of, generally, as a
bundle of information with three parts:

   * an ID, indicating which revision you are making a statement about

   * a name indicating the type of statement you are making, such as
     "changelog", "date" or "testresult"

   * a value indicating the remaining detail of the statement, such as
     "fixed a bug", "March 9th" or "1"

   For example, if you want to say that a particular revision was
composed on April 4, 2003, you might make a statement like this:

           +------------------------------------------------------+
           |  revision ID                                         |
           |  a2eeaa28574141a7d48fa1cc2802070150b93ec4            |
           +--------------------------+---------------------------+
           |  statement name          |  statement value          |
           |  "date"                  |  "2003-04-04T07:39:51"    |
           +--------------------------+---------------------------+

   In an ideal world, these are all the parts of a statement we would
need in order to go about our work. In the real world, however, there
are sometimes malicious people who would make false or misleading
statements; so we need a way to verify that a particular person made a
particular statement about a revision. We therefore will add two more
pieces of information to our bundle:

   * a key which identifies the person making a statement

   * a signature -- just a large number with particular properties --
     certifying the fact that the person made the statement

   When these 2 items accompany a statement, we call the total bundle of
5 items a "certificate", or cert. A cert makes a statement in a secure
fashion. The security of the signature in a cert is derived from the
RSA cryptography system, the details of which are beyond the scope of
this document.

           +------------------------------------------------------+
           |  revision ID                                         |
           |  a2eeaa28574141a7d48fa1cc2802070150b93ec4            |
           +--------------------------+---------------------------+
           |  cert name               |  cert value               |
           |  "date"                  |  "2003-04-04T07:39:51"    |
           +--------------------------+---------------------------+
           |  signed by key           |  signature                |
           |  "jrh@example.com"       |  "a02380def....0983fe90"  |
           +--------------------------+---------------------------+

   Monotone uses certs extensively. Any "extra" information which needs
to be stored, transmitted or retrieved -- above and beyond files,
manifests, and revisions -- is kept in the form of certs. This includes
change logs, time and date records, branch membership, authorship, test
results, and more. When monotone makes a decision about storing,
transmitting, or extracting files, manifests, or revisions, the
decision is often based on certs it has seen, and the trustworthiness
you assign to those certs.

   The RSA cryptography system -- and therefore monotone itself --
requires that you exchange special "public" numbers with your friends,
before they will trust certificates signed by you. These numbers are
called "public keys". Giving someone your public key does not give them
the power to impersonate you, only to verify signatures made by you.
Exchanging public keys should be done over a trusted medium, in person,
or via a trusted third party. Advanced secure key exchange techniques
are beyond the scope of this document.


File: monotone.info,  Node: Storage and workflow,  Next: Forks and merges,  Prev: Certificates,  Up: Concepts

1.5 Storage and workflow
========================

Monotone moves information in and out of four different types of
storage:

   * a keystore in your home directory

   * a workspace in the local file system

   * a local database in the local file system

   * a remote database elsewhere on the internet

   The "keystore" is a directory `.monotone/keys' in your home directory
which contains copies of all your private keys. Each key is stored in a
file whose name is the key identifier with some characters converted to
underscores.  When you use a key to sign a cert, the public half of
that key is copied into your local database along with the cert.

   All information passes _through_ your local database, en route to
some other destination. For example, when changes are made in a
workspace, you may save those changes to your database, and later you
may synchronize your database with someone else's. Monotone will not
move information directly between a workspace and a remote database, or
between workspaces. Your local database is always the "switching point"
for communication.

                  pull, push, sync
            (untrusted network exchanges)
                 _________/\________
                /                   \

         +-------------+      +------------+      +-------------+
         |             |      |            |      |             |
         |  remote db  | <==> |  local db  | <==> |  workspace  |
         |             |      |            |      |             |
         +-------------+      +------------+      +-------------+

                                     \________  _______/
                                              \/
                                       commit, update
                                 (certified local exchanges)

   A "workspace" is a tree of files in your file system, arranged
according to the list of file paths and IDs in a particular manifest. A
special directory called `_MTN' exists in the root of any workspace.
Monotone keeps some special files in the `_MTN' directory, in order to
track changes you make to your workspace.  If you ever want to know if
a directory is a monotone workspace, just look for this `_MTN'
directory.

   Aside from the special `_MTN' directory, a workspace is just a
normal tree of files. You can directly edit the files in a workspace
using a plain text editor or other program; monotone will automatically
notice when you make this kind of change, and include them in the next
commit.

   If you add files, remove files, or move files within your workspace,
you must tell monotone explicitly what you are doing, as these actions
cannot be deduced. Monotone stores these changes in `_MTN/revision';
they will be part of the next commit.

   If you do not yet have a workspace, you can "check out" a workspace
from a database, or construct one from scratch and "add" it into a
database. As you work, you will occasionally "commit" changes you have
made in a workspace to a database, and "update" a workspace to receive
changes that have arrived in a database. Committing and updating take
place purely between a database and a workspace; the network is not
involved.

        -----------------     check out,      workspace
       (                 )    or update      +----------------
        -----------------     ---------->    |
       |                 |                   |  src/func.c
       |      local      |   <----------     |  src/func.h
       |     database    |    add,           |  src/main.c
       |                 |    or commit      |  Makefile
       \_________________/                   |  _MTN/
                                             |

   A "database" is a single, regular file. You can copy or back it up
using standard methods. Typically you keep a database in your home
directory. Databases are portable between different machine types. You
can have multiple databases and divide your work between them, or keep
everything in a single database if you prefer. You can dump portions of
your database out as text, and read them back into other databases, or
send them to your friends.  Underneath, databases are accessed using a
standard, robust data manager, which makes using even very large
databases efficient.  In dire emergencies, you can directly examine and
manipulate a database using a simple SQL interface.

   A database contains many files, manifests, revisions, and
certificates, some of which are not immediately of interest, some of
which may be unwanted or even false. It is a collection of information
received from network servers, workspaces, and other databases. You can
inspect and modify your databases without affecting your workspaces,
and vice-versa.

   Monotone knows how to exchange information in your database with
other remote databases, using an interactive protocol called "netsync".
It supports three modes of exchange: pushing, pulling, and
synchronizing. A "pull" operation copies data from a remote database to
your local database. A "push" operation copies data from your local
database to a remote database. A "sync" operation copies data both
directions. In each case, only the data missing from the destination is
copied. The netsync protocol calculates the data to send "on the fly"
by exchanging partial hash values of each database.

       -----------------                    -----------------
      (                 )                  (                 )
       -----------------    --- pull --->   -----------------
      |                 |                  |                 |
      |      remote     |  <--- sync --->  |      local      |
      |     database    |                  |     database    |
      |                 |  <--- push ---   |                 |
      \_________________/                  \_________________/

   In general, work flow with monotone involves 3 distinct stages:

   * When you commit changes from your workspace to your database, your
     database stores the changes but does not communicate with the
     network. Your commits happen immediately, without consulting any
     other party, and do not require network connectivity.

   * When you are ready to exchange work with someone else, you can
     push, pull, or sync with other databases on the network. When you
     talk to other servers on the network, your database may change,
     but your workspace will not. In fact, you do not need a workspace
     at all when exchanging work.

   * When you update your workspace, some (but not all) of the changes
     which your database received from the network are applied to your
     workspace. The network is not consulted during updates.

   The last stage of workflow is worth clarifying: monotone does _not_
blindly apply all changes it receives from a remote database to your
workspace.  Doing so would be very dangerous, because remote databases
are not always trustworthy systems. Rather, monotone evaluates the
certificates it has received along with the changes, and decides which
particular changes are safe and desirable to apply to your workspace.

   You can always adjust the criteria monotone uses to judge the
trustworthiness and desirability of changes in your database. But keep
in mind that it always uses _some_ criteria; receiving changes from a
remote server is a _different_ activity than applying changes to a
workspace. Sometimes you may receive changes which monotone judges to
be untrusted or bad; such changes may stay in your database but will
_not_ be applied to your workspace.

   Remote databases, in other words, are just untrusted "buckets" of
data, which you can trade with promiscuously. There is no trust implied
in communication.


File: monotone.info,  Node: Forks and merges,  Next: Branches,  Prev: Storage and workflow,  Up: Concepts

1.6 Forks and merges
====================

So far we have been talking about revisions as though each logically
follows exactly one revision before it, in a simple sequence of
revisions.

            +-----------------------+
            |  parent revision      |
            +-----------------------+
                     |
                     |
            +-----------------------+
            |  child revision       |
            +-----------------------+
                     |
                     |
            +-----------------------+
            |  grandchild revision  |
            +-----------------------+

   This is a rosy picture, but sometimes it does not work out this way.
Sometimes when you make new revisions, other people are simultaneously
making new revisions as well, and their revisions might be derived from
the same parent as yours, or contain different changesets. Without loss
of generality, we will assume simultaneous edits only happen
two-at-a-time; in fact many more edits may happen at once but our
reasoning will be the same.

   We call this situation of simultaneous edits a "fork", and will
refer to the two children of a fork as the left child and right child.
In a large collection of revisions with many people editing files,
especially on many different computers spread all around the world,
forks are a common occurrence.

                  +-----------------+
                  | parent revision |
                  +-----------------+
                         |   |
                +--------+   +---------+
                |                      |
          +-------------+     +--------------+
          | left child  |     | right child  |
          +-------------+     +--------------+

   If we analyze the changes in each child revision, we will often find
that the changeset between the parent and the left child are unrelated
to the changeset between the parent and the right child. When this
happens, we can usually "merge" the fork, producing a common grandchild
revision which contains both changesets.

                  +-----------------+
                  | parent revision |
                  +-----------------+
                         |   |
                +--------+   +---------+
                |                      |
          +-------------+     +--------------+
          | left child  |     | right child  |
          +-------------+     +--------------+
                |                      |
                +--------+   +---------+
                         |   |
                  +-----------------+
                  | merged revision |
                  +-----------------+


File: monotone.info,  Node: Branches,  Prev: Forks and merges,  Up: Concepts

1.7 Branches
============

Sometimes, people intentionally produce forks which are _not supposed
to be merged_; perhaps they have agreed to work independently for a
time, or wish to change their files in ways which are not logically
compatible with each other. When someone produces a fork which is
supposed to last for a while (or perhaps permanently) we say that the
fork has produced a new "branch". Branches tell monotone which
revisions you would like to merge, and which you would like to keep
separate.

   You can see all the available branches using `mtn list branches'.

1.7.1 Heads and merging
-----------------------

Branches are indicated with certs.  The cert name `branch' is reserved
for use by monotone, for the purpose of identifying the revisions which
are members of a branch. A `branch' cert has a symbolic "branch name"
as its value. When we refer to "a branch", we mean all revisions with a
common branch name in their `branch' certs.

   For example, suppose you are working on a program called "wobbler".
You might develop many revisions of wobbler and then decide to split
your revisions into a "stable branch" and an "unstable branch", to help
organize your work. In this case, you might call the new branches
"wobbler-stable" and "wobbler-unstable". From then on, all revisions in
the stable branch would get a cert with name `branch' and value
`wobbler-stable'; all revisions in the unstable branch would get a cert
with name `branch' and value `wobbler-unstable'. When a
`wobbler-stable' revision forks, the children of the fork will be
merged. When a `wobbler-unstable' revision forks, the children of the
fork will be merged. However, the `wobbler-stable' and
`wobbler-unstable' branches will not be merged together, despite having
a common ancestor.

                        +--------------------------+
                        | common ancestor revision |
                        +--------------------------+
                               |          |
                     +---------+          +---------+
                     |                              |
            +-----------------+            +-------------------+
            | stable revision |            | unstable revision |
            +-----------------+            +-------------------+
                   | |                               | |
           +-------+ +-------+               +-------+ +-------+
           |                 |               |                 |
     +-------------+ +--------------+  +---------------+ +----------------+
     | left stable | | right stable |  | left unstable | | right unstable |
     |   child     | |     child    |  |   child       | |     child      |
     +-------------+ +--------------+  +---------------+ +----------------+
           |                  |              |                  |
           +-------+ +--------+              +-------+ +--------+
                   | |                               | |
            +----------------+                +------------------+
            | merged stable  |                | merged unstable  |
            |   revision     |                |     revision     |
            +----------------+                +------------------+

     \_____________  _______________/  \_______________  _________________/
                   \/                                  \/
              stable branch                     unstable branch

   For each branch, the set of revisions with _no children_ is called
the "heads" of the branch. Monotone can automatically locate, and
attempt to merge, the heads of a branch. If it fails to automatically
merge the heads, it may ask you for assistance or else fail cleanly,
leaving the branch alone.

   For example, if a fork's left child has a child of its own (a "left
grandchild"), monotone will merge the fork's right child with the left
grandchild, since those revisions are the heads of the branch. It will
not merge the left child with the right child, because the left child
is not a member of the heads.

                    +-----------------+
                    | parent revision |
                    +-----------------+
                           |       |
                  +--------+       |
                  |                |
            +-------------+        |
            | left child  |        |
            +-------------+        |
                  |                |
     *************|****************|************
     *            |                |           *
     *  +-----------------+  +-------------+   *
     *  | left grandchild |  | right child |   *  the heads of the branch
     *  +-----------------+  +-------------+   *    (before the merge)
     *            |                |           *
     *************|****************|************
                  |                |
                  +--------+   +---+
                           |   |
                    +-----------------+
                    | merged revision |
                    +-----------------+

   When there is only one revision in the heads of a branch, we say that
the heads are merged, or more generally that the branch is merged,
since the heads is the logical set of candidates for any merging
activity. If there are two or more revisions in the heads of a branch,
and you ask to merge the branch, monotone will merge them two-at-a-time
until there is only one.

1.7.2 Branch Names
------------------

The branch names used in the above section are fine for an example, but
they would be bad to use in a real project.  The reason is, monotone
branch names should be _globally_ unique, over all branches in the
world.  Otherwise, when your branch eventually gets distributed, you
could get name collisions with other people's work.

   Having two separate projects with the same monotone branch names
means those projects cannot be stored in the same database. In general,
monotone supports storing unrelated branches in a single database,
which simplifies servers. But that requires unique branch names, so
ensuring globally unique branch names allows using globally accessible
monotone servers.

   monotone does _not_ support renaming branches (because that would be
modifying history), so choosing a good branch name up front is
important. It is possible to work around this by propagating from your
branch to one with a better name, but that is a painful process if
there are many people using the original branch name.

   Even if you are _absolutely_ sure that your branch will never be
distributed, things could change in the future!

   Fortunately, we have a handy source of globally unique names -- the
DNS system. When naming a branch, always prepend the reversed, fully
qualified, domain name of a host that you control or are otherwise
authorized to use.  For example, monotone development happens on the
branch `net.venge.monotone', because `venge.net' belongs to monotone's
original author.  The idea is that this way, you can coordinate with
other people using a host to make sure there are no conflicts -- in the
example, monotone's original author can be certain that no-one else
using `venge.net' will start up a different program named `monotone'.
If you work for Yoyodyne, Inc. (owners of yoyodyne.com), then all your
branch names should look like `com.yoyodyne._something_'.

   What the `_something_' part looks like is up to you, but usually the
first part is the project name (the `monotone' in
`net.venge.monotone'), and then possibly more stuff after that to
describe a particular branch.  For example, monotone's win32 support
was initially developed on the branch `net.venge.monotone.win32' (for
more information, see *note Naming Conventions::).

   It has to be noted that earlier versions of monotone enforced no
restrictions on branch names.  Newer versions, starting with 0.99,
exclude a set of control characters though, which mostly denote either
meta characters in monotone's URI syntax or are used in globs to
resolve branch patterns.  These characters are `?', `,', `*', `%', `+',
`{', `}', `[', `]', `!' and `^'.  Additionally, `-' is deprecated as
first character of a branch name, since it is used to denote branch
exclude patterns in the aforementioned URI syntax.

   monotone warns on the creation of branch names which violate one of
the above restrictions and gives further directions.  Future versions
of monotone are likely to enforce these restrictions by disallowing
such branch names completely.


File: monotone.info,  Node: Tutorial,  Next: Advanced Uses,  Prev: Concepts,  Up: Top

2 Tutorial
**********

This chapter illustrates the basic uses of monotone by means of an
example, fictional software project.

2.1 Issues
==========

Before we walk through the tutorial, there are two minor issues to
address: standard options and revision selectors.

2.1.1 Standard Options
----------------------

Before operating monotone, two important command-line options should be
explained.

   * Most commands operate on a database, which is selected with the
     `--db' option.

   * Many commands operate on a subset of the database, called a
     branch, which is selected with the `--branch' option.

   Monotone will cache the settings for these options in your
workspace, so ordinarily once you have checked out a project, you will
not need to specify them again.  We will therefore only mention these
arguments in the first example.

2.1.2 Revision Selectors
------------------------

Many commands require you to supply 40-character SHA1 values as
arguments, which identify revisions. These "revision IDs" are tedious
to type, so monotone permits you to supply "revision selectors" rather
than complete revision IDs. Selectors are a more "human friendly" way
of specifying revisions by combining certificate values into unique
identifiers. This "selector" mechanism can be used anywhere a revision
ID would normally be used. For details on selector syntax, see *note
Selectors::.

   We are now ready to explore our fictional project.

2.2 The Fictional Project
=========================

Our fictional project involves 3 programmers cooperating to write
firmware for a robot, the JuiceBot 7, which dispenses fruit juice. The
programmers are named Jim, Abe and Beth.

   * Jim lives in Japan, and owns JuiceBot Inc. You will know when
     we're talking about Jim, because everything he does involves the
     letter "j".

   * Abe lives in Australia and writes code related to apple juice. You
     will know when we're talking about Abe, because everything he does
     involves the letter "a".

   * Beth lives in Brazil and writes code related to banana juice. You
     will know when we're talking about Beth, because everything she
     does involves the letter "b".

   In our example the programmers work privately on laptops, and are
usually _disconnected_ from the network. They share no storage system.
Thus when each programmer enters a command, it affects only his or her
own computer, unless otherwise stated.

   In the following, our fictional project team will work through
several version control tasks. Some tasks must be done by each member
of our example team; other tasks involve only one member.

* Menu:

* Creating a Database::
* Generating Keys::
* Starting a New Project::
* Adding Files::
* Committing Work::
* Basic Network Service::
* Synchronising Databases::
* Making Changes::
* Dealing with a Fork::
* Branching and Merging::
* Network Service Revisited::


File: monotone.info,  Node: Creating a Database,  Next: Generating Keys,  Prev: Tutorial,  Up: Tutorial

2.3 Creating a Database
=======================

The first step Jim, Abe and Beth each need to perform is to create a
new database. This is done with the `mtn db init' command, providing a
`--db' option to specify the location of the new database. Each
programmer creates their own database, which will reside in their home
directory and store all the revisions, files and manifests they work on.

   In real life, most people prefer to keep one database for each
project they work on.  If we followed that convention here in the
tutorial, though, then all the databases would be called
`juicebot.mtn', and that would make things more confusing to read.  So
instead, we'll have them each name their database after themselves.

   Thus Jim issues the command:

     $ mtn db init --db=~/jim.mtn

   and Abe issues the command:

     $ mtn db init --db=~/abe.mtn

   Beth decides to use monotone's built-in database management
functionality.  monotone then expects to find managed database files in
a list of directories (default `$HOME/.monotone/databases' on Unix and
`%APPDATA%\monotone\databases' on Windows, see *note Managed
Databases:: for more info) and acts upon those by knowing only their
file or basename.

   To create a new managed database, Beth issues the `mtn db init'
command like this:

     $ mtn db init --db=:beth

   Beth can distinguish a managed database name from an unmanaged one by
the leading colon in its name.  This special alias can now be used
interchangeably in every monotone invocation.  If Beth wants to see
where monotone actually created the database and what other databases
monotone knows of, she uses the `*note mtn list databases::' command
(or `mtn ls dbs') for that.  We'll come back to this in a bit.


File: monotone.info,  Node: Generating Keys,  Next: Starting a New Project,  Prev: Creating a Database,  Up: Tutorial

2.4 Generating Keys
===================

Now Jim, Abe and Beth must each generate an RSA key pair for
themselves. This step requires choosing a key identifier. Typical key
identifiers are similar to email addresses, possibly modified with some
prefix or suffix to distinguish multiple keys held by the same owner.
Our example programmers will use their email addresses at the fictional
"juicebot.co.jp" domain name. When we ask for a key to be generated,
monotone will ask us for a passphrase. This phrase is used to encrypt
the key when storing it on disk, as a security measure.

   Jim does the following:

     $ mtn genkey jim@juicebot.co.jp
     enter passphrase for key ID [jim@juicebot.co.jp] (...): <Jim enters his passphrase>
     confirm passphrase for key ID [jim@juicebot.co.jp] (...): <Jim confirms his passphrase>
     mtn: generating key-pair 'jim@juicebot.co.jp'
     mtn: storing key-pair 'jim@juicebot.co.jp' in /home/jim/.monotone/keys
     mtn: key 'jim@juicebot.co.jp' has hash '398cb10dcd4fadf4f7849a3734b626a83e0bb2ae'

   Abe does something similar:

     $ mtn genkey abe@juicebot.co.jp
     enter passphrase for key ID [abe@juicebot.co.jp] (...): <Abe enters his passphrase>
     confirm passphrase for key ID [abe@juicebot.co.jp] (...): <Abe confirms his passphrase>
     mtn: generating key-pair 'abe@juicebot.co.jp'
     mtn: storing key-pair 'abe@juicebot.co.jp' in /home/abe/.monotone/keys
     mtn: key 'abe@juicebot.co.jp' has hash '62d8d1798e716868acde75c0fc4c84760003863d'

   as does Beth:

     $ mtn genkey beth@juicebot.co.jp
     enter passphrase for key ID [beth@juicebot.co.jp] (...): <Beth enters her passphrase>
     confirm passphrase for key ID [beth@juicebot.co.jp] (...): <Beth confirms her passphrase>
     mtn: generating key-pair 'beth@juicebot.co.jp'
     mtn: storing key-pair 'beth@juicebot.co.jp' in /home/beth/.monotone/keys
     mtn: key 'beth@juicebot.co.jp' has hash 'c1d47c065a21f1e1c4fbdefaa2f37bd2c15ee4b1'

   Each programmer has now generated a key pair and placed it in their
keystore. Each can list the keys in their keystore, to ensure the
correct key was generated. For example, Jim might see this:

     $ mtn list keys

     [public keys]
     398cb10dcd4fadf4f7849a3734b626a83e0bb2ae jim@juicebot.co.jp   (*)
     (*) - only in /home/jim/.monotone/keys/


     [private keys]
     398cb10dcd4fadf4f7849a3734b626a83e0bb2ae jim@juicebot.co.jp

   The hexadecimal string printed out before each key name is a
_fingerprint_ of the key, and can be used to verify that the key you
have stored under a given name is the one you intended to store.
Monotone will never permit one keystore to store two keys with the same
fingerprint, however distincts keys with equal names are possible.

   This output shows one private and one public key stored under the
name `jim@juicebot.co.jp', so it indicates that Jim's key-pair has been
successfully generated and stored. On subsequent commands, Jim will need
to re-enter his passphrase in order to perform security-sensitive tasks.

   Pretty soon Jim gets annoyed when he has to enter his passphrase
every time he invokes `mtn' (and, more importantly, it simplifies the
tutorial text to skip the passphrase prompts) so he decides to use
_ssh-agent_ to store his key. He does this by using the
`ssh_agent_export' command to export his key into a format that
ssh-agent can understand and adding it with `ssh-add'.

     $ mtn ssh_agent_export ~/.ssh/id_monotone
     enter passphrase for key ID [user@example.com] (1234abcd...):
     enter new passphrase for key ID [user@example.com] (1234abcd...):
     confirm passphrase for key ID [user@example.com] (1234abcd...):
     $ chmod 600 ~/.ssh/id_monotone

   From now on, Jim just needs to add his key to ssh-agent when he logs
in and he will not need to enter his passphrase every time he uses
monotone.

     $ ssh-agent /bin/bash
     $ ssh-add ~/.ssh/id_monotone
     Enter passphrase for /home/user/.ssh/id_monotone:
     Identity added: /home/user/.ssh/id_monotone (/home/user/.ssh/id_monotone)
     $ mtn ci -m"Changed foo to bar"
     $ mtn push

   The following procedure is deprecated and not suggested for general
use as it is very insecure.

   Jim isn't very worried about security so he decides to store his
passphrase in his `monotonerc' file.  He does this by writing a _hook
function_ which returns the passphrase:

     $ mkdir ~/.monotone
     $ cat >>~/.monotone/monotonerc
     function get_passphrase(key_identity)
       return "jimsekret"
     end
     ^D

   Now whenever monotone needs his passphrase, it will call this
function instead of prompting him to type it.  Note that we are
appending the new hook to the (possibly existing) file.  We do this to
avoid losing other changes by mistake; therefore, be sure to check that
no other `get_passphrase' function appears in the configuration file.

   Abe and Beth do the same, with their secret passphrases.


File: monotone.info,  Node: Starting a New Project,  Next: Adding Files,  Prev: Generating Keys,  Up: Tutorial

2.5 Starting a New Project
==========================

Before he can begin work on the project, Jim needs to create a
workspace -- a directory whose contents monotone will keep track of.
Often, one works on projects that someone else has started, and creates
workspaces with the `checkout' command, which you'll learn about later.
Jim is starting a new project, though, so he does something a little
bit different.  He uses the `mtn setup' command to create a new
workspace.

   This command creates the named directory (if it doesn't already
exist), and creates the `_MTN' directory within it.  The `_MTN'
directory is how monotone recognizes that a directory is a workspace,
and monotone stores some bookkeeping files within it.  For instance,
command line values for the `--db', `--branch' or `--key' options to
the `setup' command will be cached in a file called `_MTN/options', so
you don't have to keep passing them to monotone all the time.

   He chooses `jp.co.juicebot.jb7' as a branch name. (See *note Naming
Conventions:: for more information about appropriate branch names.)
Jim then creates his workspace:

     /home/jim$ mtn --db=jim.mtn --branch=jp.co.juicebot.jb7 setup juice
     /home/jim$ cd juice
     /home/jim/juice$

   Notice that Jim has changed his current directory to his newly
created workspace. For the rest of this example we will assume that
everyone issues all further monotone commands from their workspace
directories.


File: monotone.info,  Node: Adding Files,  Next: Committing Work,  Prev: Starting a New Project,  Up: Tutorial

2.6 Adding Files
================

Next Jim decides to add some files to the project. He writes up a file
containing the prototypes for the JuiceBot 7:

     $ mkdir include
     $ cat >include/jb.h
     /* Standard JuiceBot hw interface */

     #define FLOW_JUICE 0x1
     #define POLL_JUICE 0x2
     int spoutctl(int port, int cmd, void *x);

     /* JuiceBot 7 API */

     #define APPLE_SPOUT 0x7e
     #define BANANA_SPOUT 0x7f
     void dispense_apple_juice ();
     void dispense_banana_juice ();
     ^D

   Then adds a couple skeleton source files which he wants Abe and Beth
to fill in:

     $ mkdir src
     $ cat >src/apple.c
     #include "jb.h"

     void
     dispense_apple_juice()
     {
       /* Fill this in please, Abe. */
     }
     ^D
     $ cat >src/banana.c
     #include "jb.h"

     void
     dispense_banana_juice()
     {
       /* Fill this in please, Beth. */
     }
     ^D

   Now Jim tells monotone to add these files to its record of his
workspace.  He specifies one filename and one directory; monotone
recursively scans the directory and adds all its files.

     $ mtn add -R include/jb.h src
     mtn: adding include/jb.h to workspace manifest
     mtn: adding src/apple.c to workspace manifest
     mtn: adding src/banana.c to workspace manifest

   This command produces a record of Jim's intentions in a special file
called `_MTN/revision', stored in the workspace. The file is plain text:

     $ cat _MTN/revision
     format_version "1"

     new_manifest [0000000000000000000000000000000000000002]

     old_revision []

     add_dir ""

     add_dir "include"

     add_dir "src"

     add_file "include/jb.h"
      content [f6996ce2dfc5d32bda8b574c3e9ce75db8d55492]

     add_file "src/apple.c"
      content [1ce885d2cc59842ff16785834391e864068fbc3c]

     add_file "src/banana.c"
      content [ad88bbbb1b7507ddff26be67efd91d95e069afb6]

   You will never have to look at this file, but it is nice to know that
it is there.

   Jim then gets up from his machine to get a coffee. When he returns
he has forgotten what he was doing. He asks monotone:

     $ mtn status
     ----------------------------------------------------------------------
     Revision: 493bda86628fd72c992eb56f73899db9ead3cf6f
     Author:   jim@juicebot.co.jp
     Date:     2004-10-26T02:53:08
     Branch:   jp.co.juicebot.jb7

     Changes

       added
       added    include
       added    src
       added    include/jb.h
       added    src/apple.c
       added    src/banana.c

   The output of this command tells Jim that his edits, so far,
constitute only the addition of some files and directories.

   Jim wants to see the actual details of the files he added, however,
so he runs a command which prints out the revision _and_ a GNU "unified
diff" of the patches involved in the changeset:

     $ mtn diff
     #
     # old_revision []
     #
     # add_dir ""
     #
     # add_dir "include"
     #
     # add_dir "src"
     #
     # add_file "include/jb.h"
     #  content [f6996ce2dfc5d32bda8b574c3e9ce75db8d55492]
     #
     # add_file "src/apple.c"
     #  content [1ce885d2cc59842ff16785834391e864068fbc3c]
     #
     # add_file "src/banana.c"
     #  content [ad88bbbb1b7507ddff26be67efd91d95e069afb6]
     #
     ============================================================
     --- include/jb.h        f6996ce2dfc5d32bda8b574c3e9ce75db8d55492
     +++ include/jb.h        f6996ce2dfc5d32bda8b574c3e9ce75db8d55492
     @ -0,0 +1,13 @
     +/* Standard JuiceBot hw interface */
     +
     +#define FLOW_JUICE 0x1
     +#define POLL_JUICE 0x2
     +#define SET_INTR 0x3
     +int spoutctl(int port, int cmd, void *x);
     +
     +/* JuiceBot 7 API */
     +
     +#define APPLE_SPOUT 0x7e
     +#define BANANA_SPOUT 0x7f
     +void dispense_apple_juice ();
     +void dispense_banana_juice ();
     ============================================================
     --- src/apple.c 1ce885d2cc59842ff16785834391e864068fbc3c
     +++ src/apple.c 1ce885d2cc59842ff16785834391e864068fbc3c
     @ -0,0 +1,7 @
     +#include "jb.h"
     +
     +void
     +dispense_apple_juice()
     +{
     +  /* Fill this in please, Abe. */
     +}
     ============================================================
     --- src/banana.c        ad88bbbb1b7507ddff26be67efd91d95e069afb6
     +++ src/banana.c        ad88bbbb1b7507ddff26be67efd91d95e069afb6
     @ -0,0 +1,7 @
     +#include "jb.h"
     +
     +void
     +dispense_banana_juice()
     +{
     +  /* Fill this in please, Beth. */
     +}


File: monotone.info,  Node: Committing Work,  Next: Basic Network Service,  Prev: Adding Files,  Up: Tutorial

2.7 Committing Work
===================

Satisfied with the work he's done, Jim wants to save his changes.  He
then commits his workspace, which causes monotone to process the
`_MTN/revision' file and record the file contents, manifest, and
revision into the database. Since he provided a branch name when he ran
`setup', monotone will use this as the default branch name when he
commits.

     $ mtn commit --message="initial checkin of project"
     mtn: beginning commit on branch 'jp.co.juicebot.jb7'
     mtn: committed revision 493bda86628fd72c992eb56f73899db9ead3cf6f

   When monotone committed Jim's revision, it updated `_MTN/revision'
to record the workspace's new base revision ID. Jim can use this
revision ID in the future, as an argument to the `checkout' command, if
he wishes to return to this revision:

     $ mtn automate get_base_revision_id
     493bda86628fd72c992eb56f73899db9ead3cf6f

   Monotone also generated a number of certificates attached to the new
revision, and made sure that the database contained a copy of Jim's
public key. These certs store metadata about the commit. Jim can ask
monotone for a list of certs on this revision.

     $ mtn ls certs 493bda86628fd72c992eb56f73899db9ead3cf6f
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : branch
     Value : jp.co.juicebot.jb7
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : date
     Value : 2004-10-26T02:53:08
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : author
     Value : jim@juicebot.co.jp
     -----------------------------------------------------------------
     Key   : jim@juicebot.co.jp (398cb10d...)
     Sig   : ok
     Name  : changelog
     Value : initial checkin of project

   The output of this command has a block for each cert found. Each
block has 4 significant pieces of information. The first indicates the
signer of the cert, in this case `jim@juicebot.co.jp'. The second
indicates whether this cert is "ok", meaning whether the RSA signature
provided is correct for the cert data. The third is the cert name, and
the fourth is the cert value. This list shows us that monotone has
confirmed that, according to `jim@juicebot.co.jp', the revision
`493bda86628fd72c992eb56f73899db9ead3cf6f' is a member of the branch
`jp.co.juicebot.jb7', written by `jim@juicebot.co.jp', with the given
date and changelog.

   It is important to keep in mind that revisions are not "in" or "out"
of a branch in any global sense, nor are any of these cert values true
or false in any global sense. Each cert indicates that some person - in
this case Jim - would like to associate a revision with some value; it
is up to you to decide if you want to accept that association.

   Jim can now check the status of his branch using the "heads"
command, which lists all the head revisions in the branch:

     $ mtn heads
     branch 'jp.co.juicebot.jb7' is currently merged:
     493bda86628fd72c992eb56f73899db9ead3cf6f jim@juicebot.co.jp 2004-10-26T02:53:08

   The output of this command tells us that there is only one current
"head" revision in the branch `jp.co.juicebot.jb7', and it is the
revision Jim just committed. A head revision is one without any
descendants. Since Jim has not committed any changes to this revision
yet, it has no descendants.


File: monotone.info,  Node: Basic Network Service,  Next: Synchronising Databases,  Prev: Committing Work,  Up: Tutorial

2.8 Basic Network Service
=========================

Jim now decides he will make his base revision available to his
employees.  To do this, he arranges for Abe and Beth to synchronise
their databases with his, over the network.  There are two
pre-requisites for this: first, he has to get a copy of each of their
public keys; then, he has to tell monotone that the holders of those
keys are permitted to access his database. Finally, with these
pre-requisites in place, he needs to tell monotone to provide network
access to his database.

   First, Abe exports his public key:

     $ mtn --db=~/abe.mtn pubkey abe@juicebot.co.jp >~/abe.pubkey

   His public key is just a plain block of ASCII text:

     $ cat ~/abe.pubkey
     [pubkey abe@juicebot.co.jp]
     MIGdMA0GCSqGSIb3DQEBAQUAA4GLADCBhwKBgQCbaVff9SF78FiB/1nUdmjbU/TtPyQqe/fW
     CDg7hSg1yY/hWgClXE9FI0bHtjPMIx1kBOig09AkCT7tBXM9z6iGWxTBhSR7D/qsJQGPorOD
     DO7xovIHthMbZZ9FnvyB/BCyiibdWgGT0Gtq94OKdvCRNuT59e5v9L4pBkvajb+IzQIBEQ==
     [end]

   Beth also exports her public key:

     $ mtn --db=:beth pubkey beth@juicebot.co.jp >~/beth.pubkey

   Then Abe and Beth both send their keys to Jim.  The keys are not
secret, but the team members must be relatively certain that they are
exchanging keys with the person they intend to trust, and not some
malicious person pretending to be a team member. Key exchange may
involve sending keys over an encrypted medium, or meeting in person to
exchange physical copies, or any number of techniques. All that
matters, ultimately, is that Jim receives both Abe's and Beth's key in
a way that he can be sure of.

   So eventually, after key exchange, Jim has the public key files in
his home directory. He tells monotone to read the associated key packets
into his database:

     $ cat ~/abe.pubkey ~/beth.pubkey | mtn --db=~/jim.mtn read
     mtn: read 2 packets

   Now Jim's monotone is able to identify Beth and Abe, and he is ready
to give them permission to access his database.  He does this by
editing a pair of small files in his `~/.monotone' directory:

     $ cat >>~/.monotone/read-permissions
     pattern "*"
     allow "abe@juicebot.co.jp"
     allow "beth@juicebot.co.jp"
     ^D

     $ cat >>~/.monotone/write-permissions
     abe@juicebot.co.jp
     beth@juicebot.co.jp
     ^D

   These files are read by the default monotone hooks that will decide
whether remote monotone users will be allowed access to Jim's database,
identified by the named keys.

   Jim then makes sure that his TCP port 4691 is open to incoming
connections, adjusting his firewall settings as necessary, and runs the
monotone `serve' command:

     $ mtn --db=jim.mtn serve

   This command starts monotone listening on all network interfaces of
his laptop on the default port 4691, serving everything in his database.


File: monotone.info,  Node: Synchronising Databases,  Next: Making Changes,  Prev: Basic Network Service,  Up: Tutorial

2.9 Synchronising Databases
===========================

With Jim's server preparations done, now Abe is ready to fetch Jim's
code. To do this he issues the monotone `sync' command:

     $ mtn --db=abe.mtn sync "mtn://jim-laptop.juicebot.co.jp?jp.co.juicebot.jb7*"
     mtn: connecting to mtn://jim-laptop.juicebot.co.jp
     mtn: first time connecting to server mtn://jim-laptop.juicebot.co.jp
     mtn: I'll assume it's really them, but you might want to double-check
     mtn: their key's fingerprint: 9e9e9ef1d515ad58bfaa5cf282b4a872d8fda00c
     mtn: warning: saving public key for jim@juicebot.co.jp to database
     mtn: finding items to synchronize:
     mtn: bytes in | bytes out | revs in | revs out | revs written
     mtn:     2587 |      1025 |       1 |        0 |            1
     mtn: successful exchange with mtn://jim-laptop.juicebot.co.jp

   Abe now has, in his database, a copy of everything Jim put in the
branch. Therefore Abe can disconnect from the expensive network
connection he's on and work locally for a while. Remember that, in
monotone, work is done between workspaces in the filesystem and the
local database; network connectivity is necessary only when that work
is to be shared with others.

   As we follow the juicebot team through the next several steps, we'll
see them run the `sync' command again with Jim, and work will flow both
ways. The first time you `sync' a new database, monotone remembers the
server and branch patterns you use, and makes them the default for
future operations.

   At the end of each exchange, information about all changes in the
branch known to each database have been sent to the other party -
including the work of the third team member that had previously been
exchanged. As well as allowing each team member to learn about the
others' work, this also means that each party's laptop contains a
_backup_ of the others' work too.

   Jim, Abe and Beth will continue working like this while they're
getting started, and we'll revisit the issue of network service with
them a little later as the project grows.


File: monotone.info,  Node: Making Changes,  Next: Dealing with a Fork,  Prev: Synchronising Databases,  Up: Tutorial

2.10 Making Changes
===================

Abe decides to do some work on his part of the code. He has a copy of
Jim's database contents, but cannot edit any of that data yet.  He
begins his editing by checking out the head of the `jp.co.juicebot.jb7'
branch into a workspace, so he can edit it:

     $ mtn --db=abe.mtn --branch=jp.co.juicebot.jb7 checkout .

   Monotone unpacks the set of files in the head revision's manifest
directly into Abe's current directory.  (If he had specified something
other than `.' at the end, monotone would have created that directory
and unpacked the files into it.)  Abe then opens up one of the files,
`src/apple.c', and edits it:

     $ vi src/apple.c
     <Abe writes some apple-juice dispensing code>

   The file `src/apple.c' has now been _changed_. Abe gets up to answer
a phone call, and when he returns to his work he has forgotten what he
changed. He can ask monotone for details:

     $ mtn diff
     #
     # old_revision [493bda86628fd72c992eb56f73899db9ead3cf6f]
     #
     # patch "src/apple.c"
     #  from [1ce885d2cc59842ff16785834391e864068fbc3c]
     #    to [e2c64f6bde75a192d48d2256385df3dd7a963349]
     #
     ============================================================
     --- src/apple.c 1ce885d2cc59842ff16785834391e864068fbc3c
     +++ src/apple.c e2c64f6bde75a192d48d2256385df3dd7a963349
     @ -3,5 +3,8 @ dispense_apple_juice()
      void
      dispense_apple_juice()
      {
     -  /* Fill this in please, Abe. */
     +  spoutctl(APPLE_SPOUT, FLOW_JUICE, 1);
     +  while (spoutctl(APPLE_SPOUT, POLL_JUICE, 1) == 0)
     +    usleep (1000);
     +  spoutctl(APPLE_SPOUT, FLOW_JUICE, 0);
      }

   Satisfied with his day's work, Abe decides to commit.

     $ mtn commit

   Abe neglected to provide a `--message' option specifying the change
log on the command line.  Monotone therefore invokes an external "log
message editor" -- typically an editor like `vi' -- with an explanation
of the changes being committed and the opportunity to enter a log
message.



     *** REMOVE THIS LINE TO CANCEL THE COMMIT ***
     -- Enter a description of this change above --
     -- Edit fields below to modify certificate values --
     Branch:    right
     Author:    tester@test.net
     Date:      2010-09-11T12:03:15

     -- Modifications below this line are ignored --
     Changes against parent 493bda86628fd72c992eb56f73899db9ead3cf6f

       patched  src/apple.c

   Abe enters a single line at the top of the file, saying "polling
implementation of src/apple.c". He then saves the file and quits the
editor. Monotone extracts the message to be stored in the associated
"changelog" cert. Returning to the shell, Abe's commit completes:

     mtn: beginning commit on branch 'jp.co.juicebot.jb7'
     mtn: committed revision 42eae36587508faa664b111cefc291f0b85ef83a

   Abe then sends his new revision back to Jim:

     $ mtn sync
     mtn: connecting to mtn://jim-laptop.juicebot.co.jp
     mtn: finding items to synchronize:
     mtn:   certs |    keys | revisions
     mtn:       8 |       2 |         2
     mtn: bytes in | bytes out | revs in | revs out | revs written
     mtn:      615 |      2822 |       0 |        1 |            0
     mtn: successful exchange with mtn://jim-laptop.juicebot.co.jp

   Beth does a similar sequence. First she syncs her database with
Jim's:

     $ mtn --db=:beth sync "mtn://jim-laptop.juicebot.co.jp?jp.co.juicebot.jb7*"
     mtn: connecting to mtn://jim-laptop.juicebot.co.jp
     mtn: first time connecting to server mtn://jim-laptop.juicebot.co.jp
     mtn: I'll assume it's really them, but you might want to double-check
     mtn: their key's fingerprint: 9e9e9ef1d515ad58bfaa5cf282b4a872d8fda00c
     mtn: warning: saving public key for jim@juicebot.co.jp to database
     mtn: finding items to synchronize:
     mtn: bytes in | bytes out | revs in | revs out | revs written
     mtn:     4601 |      1239 |       2 |        0 |            1
     mtn: verifying new revisions (this may take a while)
     mtn: bytes in | bytes out | revs in | revs out | revs written
     mtn:     4601 |      1285 |       2 |        0 |            2
     mtn: successful exchange with mtn://jim-laptop.juicebot.co.jp

   She checks out a copy of the tree from her database:

     $ mtn --db=:beth --branch=jp.co.juicebot.jb7 checkout juicebot

   and since she is using a managed database, monotone automatically
remembers the connection between the newly created workspace and the
database.  She now looks at the output of `mtn list databases' and sees
the following:

     $ mtn list databases
     :beth.mtn (in /home/beth/.monotone/databases):
             jp.co.juicebot.jb7 (in /home/beth/juicebot)

   Beth realizes that, whenever the database of the workspace changes,
monotone will adapt the known paths for the old and the new database
for her.

   But let us get back to the work, Beth now start to edits the file
`src/banana.c':

     $ vi src/banana.c
     <Beth writes some banana-juice dispensing code>

   and logs her changes in `_MTN/log' right away so she does not forget
what she has done like Abe.

     $ vi _MTN/log
     * src/banana.c: Added polling implementation

   Later, she commits her work.  Monotone again invokes an external
editor for her to edit her log message, but this time it fills in the
messages she's written so far, and she simply checks them over one last
time before finishing her commit:

     $ mtn commit
     mtn: beginning commit on branch 'jp.co.juicebot.jb7'
     mtn: committed revision 85573a54105cd3220db10aa6a0713643cdf5ce6f

   And she syncs with Jim again:

     $ mtn sync
     mtn: connecting to mtn://jim-laptop.juicebot.co.jp
     mtn: finding items to synchronize:
     mtn:   certs |    keys | revisions
     mtn:      12 |       3 |         3
     mtn: bytes in | bytes out | revs in | revs out | revs written
     mtn:      709 |      2879 |       0 |        1 |            0
     mtn: successful exchange with mtn://jim-laptop.juicebot.co.jp


File: monotone.info,  Node: Dealing with a Fork,  Next: Branching and Merging,  Prev: Making Changes,  Up: Tutorial

2.11 Dealing with a Fork
========================

Careful readers will note that, in the previous section, the JuiceBot
company's work was perfectly serialized:

  1. Jim did some work

  2. Abe synced with Jim

  3. Abe did some work

  4. Abe synced with Jim

  5. Beth synced with Jim

  6. Beth did some work

  7. Beth synced with Jim

   The result of this ordering is that Jim's work entirely preceded
Abe's work, which entirely preceded Beth's work. Moreover, each worker
was fully informed of the "up-stream" worker's actions, and produced
purely derivative, "down-stream" work:

  1. Jim made revision 493bd...

  2. Abe changed revision 493bd... into revision 42eae...

  3. Beth derived revision 42eae... into revision 85573...

   This is a simple, but sadly unrealistic, ordering of events. In real
companies or work groups, people often work in parallel, _diverging_
from commonly known revisions and _merging_ their work together,
sometime after each unit of work is complete.

   Monotone supports this diverge/merge style of operation naturally;
any time two revisions diverge from a common parent revision, we say
that the revision graph has a "fork" in it. Forks can happen at any
time, and require no coordination between workers. In fact any
interleaving of the previous events would work equally well; with one
exception: if forks were produced, someone would eventually have to run
the `merge' command, and possibly resolve any conflicts in the fork.

   To illustrate this, we return to our workers Beth and Abe. Suppose
Jim sends out an email saying that the current polling juice dispensers
use too much CPU time, and must be rewritten to use the JuiceBot's
interrupt system. Beth wakes up first and begins working immediately,
basing her work off the revision 85573... which is currently in her
workspace:

     $ vi src/banana.c
     <Beth changes her banana-juice dispenser to use interrupts>

   Beth finishes and examines her changes:

     $ mtn diff
     #
     # old_revision [85573a54105cd3220db10aa6a0713643cdf5ce6f]
     #
     # patch "src/banana.c"
     #  from [d7e28a01cf6fc0f9ac04c6901dcafd77c2d32fb8]
     #    to [dd979c3c880e6a7221fcecd7148bd4afcfb3e964]
     #
     ============================================================
     --- src/banana.c        d7e28a01cf6fc0f9ac04c6901dcafd77c2d32fb8
     +++ src/banana.c        dd979c3c880e6a7221fcecd7148bd4afcfb3e964
     @ -1,10 +1,15 @
      #include "jb.h"

     +static void
     +shut_off_banana()
     +{
     +  spoutctl(BANANA_SPOUT, SET_INTR, 0);
     +  spoutctl(BANANA_SPOUT, FLOW_JUICE, 0);
     +}
     +
      void
      dispense_banana_juice()
      {
     +  spoutctl(BANANA_SPOUT, SET_INTR, &shut_off_banana);
        spoutctl(BANANA_SPOUT, FLOW_JUICE, 1);
     -  while (spoutctl(BANANA_SPOUT, POLL_JUICE, 1) == 0)
     -    usleep (1000);
     -  spoutctl(BANANA_SPOUT, FLOW_JUICE, 0);
      }

   She commits her work:

     $ mtn commit --message="interrupt implementation of src/banana.c"
     mtn: beginning commit on branch 'jp.co.juicebot.jb7'
     mtn: committed revision 90abe0f1bc354a73d42d3bff1b02946559682bd9

   And she syncs with Jim:

     $ mtn sync

   Unfortunately, before Beth managed to sync with Jim, Abe had woken up
and implemented a similar interrupt-based apple juice dispenser, but
his workspace is 42eae..., which is still "upstream" of Beth's.

     $ vi apple.c
     <Abe changes his apple-juice dispenser to use interrupts>

   Thus when Abe commits, he unknowingly creates a fork:

     $ mtn commit --message="interrupt implementation of src/apple.c"

   Abe does not see the fork yet; Abe has not actually seen _any_ of
Beth's work yet, because he has not synchronized with Jim. Since he has
new work to contribute, however, he now syncs:

     $ mtn sync

   Now Jim and Abe will be aware of the fork. Jim sees it when he sits
down at his desk and asks monotone for the current set of heads of the
branch:

     $ mtn heads
     mtn: branch 'jp.co.juicebot.jb7' is currently unmerged:
     90abe0f1bc354a73d42d3bff1b02946559682bd9 abe@juicebot.co.jp 2004-10-26T02:53:16
     951da88860a4cf7419d66ed9094d8bf24df5fb8b beth@juicebot.co.jp 2004-10-26T02:53:15

   Clearly there are two heads to the branch: it contains an un-merged
fork. Beth will not yet know about the fork, but in this case it
doesn't matter: anyone can merge the fork, and since there are no
conflicts Jim does so himself:

     $ mtn merge
     mtn: 2 heads on branch 'jp.co.juicebot.jb7'
     mtn: merge 1 / 1:
     mtn: calculating best pair of heads to merge next
     mtn: [left]  90abe0f1bc354a73d42d3bff1b02946559682bd9
     mtn: [right] 951da88860a4cf7419d66ed9094d8bf24df5fb8b
     mtn: [merged] 3aca69c7749bde9bd07fe4c92bb868bd69b2e421
     mtn: note: your workspaces have not been updated

   The output of this command shows Jim that two heads were found,
combined via a 3-way merge with their ancestor, and saved to a new
revision. This happened automatically, because the changes between the
common ancestor and heads did not conflict. If there had been a
conflict, monotone would have invoked an external merging tool to help
resolve it, or Jim could have used the `conflicts' set of commands to
resolve it (*note Conflicts::).

   After merging, the branch has a single head again, and Jim updates
his workspace.

     $ mtn update
     mtn: updating along branch 'jp.co.juicebot.jb7'
     mtn: selected update target 3aca69c7749bde9bd07fe4c92bb868bd69b2e421
     mtn: [left]  d60c18ec5e0cf1163b276f0bfdd908c1dfd53b4a
     mtn: [right] 3aca69c7749bde9bd07fe4c92bb868bd69b2e421
     mtn: updating src/apple.c
     mtn: updating src/banana.c
     mtn: updated to base revision 3aca69c7749bde9bd07fe4c92bb868bd69b2e421

   The update command selected an update target -- in this case the
newly merged head -- and performed an in-memory merge between Jim's
workspace and the chosen target. The result was then written to Jim's
workspace. If Jim's workspace had any uncommitted changes in it, they
would have been merged with the update in exactly the same manner as
the merge of multiple committed heads.

   Monotone makes very little distinction between a "pre-commit" merge
(an update) and a "post-commit" merge. Both sorts of merge use the
exact same algorithm. The major difference concerns the recoverability
of the pre-merge state: if you commit your work first, and merge after
committing, then even if the merge somehow fails (due to difficulty in a
manual merge step, for instance), your committed state is still safe.
If you update, on the other hand, you are requesting that monotone
directly modify your workspace, and while monotone will try hard not to
break anything, this process is inherently more open to error.  It is
therefore recommended that you commit your work _first_, before merging.

   If you have previously used another version control system, this may
at first seem surprising; there are some systems where you are
_required_ to update, and risk the above problems, before you can
commit.  Monotone, however, was designed with this problem in mind, and
thus _always_ allows you to commit before merging.  A good rule of
thumb is to only use `update' in workspaces with no local
modifications, or when you actually want to work against a different
base revision (perhaps because finishing your change turns out to
require some fixes made in another revision, or because you discover
that you have accidentally started working against a revision that
contains unrelated bugs, and need to back out to a working revision for
testing).


File: monotone.info,  Node: Branching and Merging,  Next: Network Service Revisited,  Prev: Dealing with a Fork,  Up: Tutorial

2.12 Branching and Merging
==========================

So by now you're familiar with making changes, sharing them with other
people, and integrating your changes with their changes.  Sometimes,
though, you may want to make some changes, and _not_ integrate them
with other people's -- or at least not right away.  One way to do this
would be to simply never run `mtn merge'; but it would quickly become
confusing to try and keep track of which changes were in which
revisions.  This is where _branches_ are useful.

   Continuing our example, suppose that Jim is so impressed by Beth's
work on banana juice support that he assigns her to work on the
JuiceBot 7's surprise new feature: muffins.  In the mean time, Abe will
continue working on the JuiceBot's basic juice-related functions.

   The changes required to support muffins are somewhat complicated, and
Beth is worried that her work might destabilize the program, and
interfere with Abe's work.  In fact, she isn't even sure her first
attempt will turn out to be the right approach; she might work on it for
a while and then decide it was a bad idea, and should be discarded.  For
all these reasons, she decides that she will work on a branch, and then
once she is satisfied with the new code, she will merge back onto the
mainline.

   She decides that since main development is in branch
`jp.co.juicebot.jb7', she will use branch `jp.co.juicebot.jb7.muffins'.
So, she makes the first few edits to the new muffins code, and commits
it on a new branch by simply passing `--branch' to commit:

     $ mtn commit --branch=jp.co.juicebot.jb7.muffins --message='autobake framework'
     mtn: beginning commit on branch 'jp.co.juicebot.jb7.muffins'
     mtn: committed revision d33caefd61823ecbb605c39ffb84705dec449857

   Alternately, she could not specify a message on the command line, and
edit the "Branch" field in the changelog editor.

   That's all there is to it -- there is now a
`jp.co.juicebot.jb7.muffins' branch, with her initial checkin on it.
She can make further checkins from the same workspace, and they will
automatically go to the muffins branch; if anyone else wants to help
her work on muffins, they can check out that branch as usual.

   Of course, while Beth is working on the new muffins code, Abe is
still making fixes to the main line.  Occasionally, Beth wants to
integrate his latest work into the muffins branch, so that her version
doesn't fall too far behind.  She does this by using the `propagate'
command:

     $ mtn propagate jp.co.juicebot.jb7 jp.co.juicebot.jb7.muffins
     mtn: propagating jp.co.juicebot.jb7 -> jp.co.juicebot.jb7.muffins
     mtn: [source] da003f115752ac6e4750b89aaca9dbba178ac80c
     mtn: [target] d0e5c93bb61e5fd25a0dadf41426f209b73f40af
     mtn: common ancestor 853b8c7ac5689181d4b958504adfb5d07fd959ab jim@juicebot.co.jp 2004-10-26T:12:44:23 found
     mtn: trying 3-way merge
     mtn: [merged] 89585b3c5e51a5a75f5d1a05dda859c5b7dde52f

   The `propagate' merges all of the new changes on one branch onto
another.

   When the muffins code is eventually stable and ready to be integrated
into the main line of development, she simply propagates the other way:

     $ mtn propagate jp.co.juicebot.jb7.muffins jp.co.juicebot.jb7
     mtn: propagating jp.co.juicebot.jb7.muffins -> jp.co.juicebot.jb7
     mtn: [source] 4e48e2c9a3d2ca8a708cb0cc545700544efb5021
     mtn: [target] bd29b2bfd07644ab370f50e0d68f26dcfd3bb4af
     mtn: common ancestor 652b1035343281a0d2a5de79919f9a31a30c9028 jim@juicebot.co.jp 2004-10-26T:15:25:05 found
     mtn: [merged] 03f7495b51cc70b76872ed019d19dee1b73e89b6

   Monotone always records the full history of all merges, and is
designed to handle an arbitrarily complicated graph of changes.  You
can make a branch, then branch off from that branch, propagate changes
between arbitrary branches, and so on; monotone will track all of it,
and do something sensible for each merge.  Of course, it is still
probably a good idea to come up with some organization of branches and
a plan for which should be merged to which other ones.  Monotone may
keep track of graphs of arbitrary complexity -- but you will have more
trouble.  Whatever arrangement of branches you come up with, though,
monotone should be able to handle it.

   If you are unsure of the name of a branch, you can list all branches
using the `ls branches' command.  This is very useful, but if you create
a lot of branches then the list can become very long and unwieldy.  To
help this monotone has the `suspend' command which partially hides
revisions/branches you are no longer using.  Further commits on hidden
branches will automatically unhide the branches.

   For example, if Beth is now finished with the muffins branch, she
can stop it from cluttering the list of branches by suspending the last
revision in that branch:

     $ mtn ls branches
     jp.co.juicebot.jb7
     jp.co.juicebot.jb7.muffins
     $ mtn heads
     mtn: branch 'jp.co.juicebot.jb7.muffins' is currently merged:
     4e48e2c9a3d2ca8a708cb0cc545700544efb5021 beth@juicebot.co.jp 2007-07-08T02:17:37
     $ mtn suspend 4e48e2c9a3d2ca8a708cb0cc545700544efb5021
     $ mtn ls branches
     jp.co.juicebot.jb7


File: monotone.info,  Node: Network Service Revisited,  Prev: Branching and Merging,  Up: Tutorial

2.13 Network Service Revisited
==============================

Up until now, Jim has been using his laptop and database as a sort of
"central server" for the company; Abe and Beth have been syncing with
Jim, and learning of each other's work via Jim's database.  This has
worked fine while the product has been in early development; Jim has
good network connectivity in Japan, and has been staying home
concentrating on programming.  He has been able to leave his laptop
connected and running all the time, while his employees in different
time-zones work and sync their databases.  This is now starting to
change, and two problems are starting to cause occasional difficulties.

   * First, Jim is finding that he has to spend more of his time
     travelling, demonstrating the new juicebot features to customers;
     thus his laptop is spending more time disconnected from the
     network, or connected at dynamic addresses where it's not
     convenient for Abe and Beth to find him and sync.

     This doesn't prevent them doing any work, but it does have some
     uncomfortable consequences: they're more likely to have to manually
     merge conflicting changes when they finally sync up and discover
     they've both come up with slightly different fixes for the same
     bug in the meantime, and they're more exposed to loss of work if
     one of them suffers a disk failure before they've had a chance to
     sync that work with another database.

   * Second, because Jim has been using the one database file both for
     his own local work, and for serving to the others in the team, he
     occasionally finds that the monotone serve process (busy syncing
     with Abe or Beth) has a lock on the database, while he's trying to
     do local work like updates or commits.

     The level of project activity is picking up, and there are more
     and more changes to be synced in the narrower window of time while
     Jim is connected. He finds he sometimes needs to take down the
     server process to do this local work, further exacerbating the
     first problem.

   The juicebot team are resourceful, and by now quite used to working
independently.  While Jim has been away travelling, Abe and Beth have
come up with their own solution to the first problem: they'll run
servers from their databases, setting them up just like Jim did
previously.  That way, if Jim's database is offline, either Beth or Abe
can run the `serve' command and provide access for the other to `sync'
with.  Beth also has the idea to create a second database for the
`serve' process, and to `sync' her development database with that
server locally, avoiding locking contention between multiple monotone
processes on the one database file.

   When Jim reappears, the next person to `sync' with him will often
pass him information about both employees' work that they've sync'ed
with each other in the meantime, just as he used to do. In fact, Jim
now finds it more convenient to initiate the sync with one of the other
servers when he has a spare moment and dynamic connectivity from a
hotel room or airport.  Changes will flow between servers automatically
as clients access them and trade with one another.

   This gets them by for a while, but there are still occasional
inconveniences.  Abe and Beth live in very different time-zones, and
don't always have reliable network connectivity, so sometimes Jim finds
that neither of them is online to sync with when he has the chance.  Jim
now also has several customers interested in beta-testing the new code,
and following changes as the bugs and issues they report are addressed.

   Jim decides it's time for a permanent server they can all sync with;
this way, everyone always knows where to go to get the latest changes,
and people can push their changes out without first calling their
friends and making sure that they have their servers running.

   Jim has rented some web server space on a service provider's shared
system for the JuiceBot Inc. public website, `www.juicebot.co.jp'; he
thinks this server will be a good place to host the central monotone
server too. He sets up a new monotone database on the server, generates
a new key specially for the server (so he doesn't have to expose his
own development private key on the shared system), and loads in the
team-members' keys:

     $ mtn --db=server.mtn db init
     $ mtn genkey monotone-server@www.juicebot.co.jp
     enter passphrase for key ID [monotone-server@www.juicebot.co.jp] (...): <Jim enters a new passphrase>
     confirm passphrase for key ID [monotone-server@www.juicebot.co.jp] (...): <Jim confirms the passphrase>
     mtn: generating key-pair 'monotone-server@www.juicebot.co.jp'
     mtn: storing key-pair 'monotone-server@www.juicebot.co.jp' in /home/jim/.monotone/keys
     mtn: key 'abe@juicebot.co.jp' has hash '78be08f7a2a316a9f7c6b0db544ed20673ea2190'
     $ cat abe.pubkey beth.pubkey jim.pubkey | mtn --db=server.mtn read
     mtn: read 3 packets

   For the team members, he sets up the permissions files on the server
much like before -- except that of course he needs to also grant his
`jim@juicebot.co.jp' key permission to access the new server.  For the
beta-testers, Jim wants to allow them read-only access just to the main
JuiceBot 7 development line, but not to any of the sub-branches where
other experimental development is going on. He adds some lines at the
top of the `~/.monotone/read-permissions' on the server, above the
broader permissions given to team-members. See *note
get_netsync_read_permitted:: for more details; the resulting file looks
like this:

     comment "Provide beta-testers with specific read-only access"
     pattern "jp.co.juicebot.jb7"
     allow "beta1@juicebot.co.jp"
     allow "beta2@juicebot.co.jp"
     continue "true"

     comment "Fall-through, and allow staff access to all branches"
     pattern "*"
     allow "abe@juicebot.co.jp"
     allow "beth@juicebot.co.jp"
     allow "jim@juicebot.co.jp"

   Jim could log in and start the monotone process manually from his
shell account on the server, perhaps under a program like screen to let
it stay running while he's away. This would be one way of giving it the
server-key's passphrase each startup, but he wants to make sure that the
server is up all the time; if the host reboots while he's travelling and
the monotone server is down until he next logs in, things aren't much
better than before.  For the server to start automatically each time,
he'll need to use the `get_passphrase' hook in the server's
`monotonerc' file again.

   Because he's running on a shared server, Jim needs to be a little
more restrictive about which interfaces and addresses his new server
process will listen on. He should only accept connections at the
address used for his website, because some of the provider's other
customers might also want to publish their own monotone projects on
this host.  Jim uses the `--bind=ADDRESS:PORT' argument like so:

     $ mtn --db=server.mtn --bind=www.juicebot.co.jp serve

   This will start monotone listening on the default port (4691), but
only on the IP address associated with `www.juicebot.co.jp'.  Jim can do
this because his hosting provider has given him a dedicated IP address
for his website.  If the hosting provider offered only a single shared
IP address belonging to the server, each customer could bind a different
port number on that address.

   While he's first testing the setup, Jim uses
`--bind=localhost:1234'. This causes the monotone process to listen
only to port 1234 on the loopback interface 127.0.0.1, which is not
accessible from the network, so Jim doesn't expose an open port to the
rest of the world until he's satisfied with the permissions
configuration.  You can cause monotone to listen on all interfaces on
port 1234 by leaving out the address part like `--bind=:1234'.

   When he's satisfied the server is set up correctly, Jim does an
initial `sync' with the new database, filling it with all the revision
history currently on his laptop. While Jim has been busy setting up the
server, Abe and Beth have kept working; the server will catch up with
their latest changes when they next sync, too.

   All of the team members now want to sync with the new monotone server
by default.  Previously, they had been syncing with Jim's laptop by
default, even if they occasionally specified another team-member's
server on the command line when Jim was away, because monotone had
remembered the first server and branch patterns used in database vars
(see *note Vars::).  These vars can be seen as follows:

     $ mtn list vars
     database: default-exclude-pattern
     database: default-include-pattern jp.co.juicebot.jb7*
     database: default-server jim-laptop.juicebot.co.jp
     known-servers: jim-laptop.juicebot.co.jp 9e9e9ef1d515ad58bfaa5cf282b4a872d8fda00c
     known-servers: abe-laptop.juicebot.co.jp a2bb16a183247af4133621f7f5aefb21a9d13855
     known-servers: www.juicebot.co.jp 120a99ch93b4f174432c13d3e3e9f2234aa92612

   The team members can reset their local database vars accordingly:

     $ mtn set database default-server www.juicebot.co.jp

   With their new server, the juicebot team have gained the convenience
of a readily available common point of reference for syncs.  However,
they also know that this is there only as a convenience, and doesn't
prevent them working as they did before:
   * The team members can still sync with each other if needed.

     Hopefully, their new server won't ever be down, but sometimes they
     might be working together while away from ready network access --
     fixing up the last few issues and finalising presentation
     materials while travelling to a sales conference, for example.
     The server will learn of these changes on the next sync.

   * The team members continue to discover multiple heads and changes
     that need merging, as before. Each team member can merge the
     heads, and will produce the same revision id if they merge to the
     same result.

     They now develop a new habit out of courtesy, though -- they try
     not to leave multiple heads and unmerged changes on the server, at
     least not for long. This saves them from repeating work, and also
     helps prevent confusion for the beta-testers.  When each team
     member is ready to `sync', they develop the habit of doing a
     `pull' from the server first.  If new revisions were received from
     the server, they first `merge' their new revisions with the
     head(s) from the server, and finally `sync' to publish their
     merged changes as one.  If the last `sync' happens to pull in new
     revisions again from the server, it means someone else has
     deposited new work at the same time, and another `merge' and
     `sync' would probably be polite.

   * Jim knows he doesn't have to keep a special backup of the new
     server's contents; if the server should fail, all the contents of
     its database can be found amongst the other team members
     (especially because no commits are done on the server itself).

     He does, however, take a copy of the server's private key, so he
     can restore that if necessary.

   * In fact, Jim realises that he can now commit a copy of the web
     site's current contents into monotone on a new branch,
     `jp.co.juicebot.www', and keep a backup of that content too.

     Now he can use monotone to work on the website offline, and let
     other team members add and edit the content; he can also preview
     changes locally before updating the production content.  He keeps
     a workspace checkout of this content in the webroot on the server,
     and runs a monotone `update' in there when he wants to bring the
     public web site up to date. Later, he'll think about using
     monotone's *note Quality Assurance:: mechanisms and Event
     Notification *note Hooks::, so that the web server can update
     itself automatically when appropriate new revisions are received.

   * Jim also knows that even if someone should break into the shared
     hosting server and tamper with the database, they won't be able to
     inject malicious code into the project, because all revisions are
     signed by the team members, and he has set his *note Trust
     Evaluation Hooks:: so he doesn't trust the server key for signing
     revisions.

     In monotone, the important trust consideration is on the _signed
     content_, rather than on the _replication path_ by which that
     content arrived in your database.


File: monotone.info,  Node: Advanced Uses,  Next: Command Reference,  Prev: Tutorial,  Up: Top

3 Advanced Uses
***************

This chapter covers slightly less common aspects of using monotone.
Some users of monotone will find these helpful, though possibly not
all. We assume that you have read through the taxonomy and tutorial,
and possibly spent some time playing with the program to familiarize
yourself with its operation.

* Menu:

* Other Transports::            Using netsync over SSH, or other transports.
* Selectors::                   Selecting revisions by certificate.
* Restrictions::                Limit workspace changes to specified files.
* Scripting::                   Running monotone from other programs.
* Inodeprints::                 Trading off safety for speed in your workspace.
* Merge Conflicts::             The various conflict types and how to resolve them.
* Workspace Collisions::        Workspace files that collide with new versioned files.
* Quality Assurance::           Integrating testing and review with development.
* Vars::                        Simple per-database configuration information.
* Managed Databases::           Default databases and database directories.
* Reserved Files::              File names with special meanings.
* Reserved Certs::              Certificate names with special meanings.
* Naming Conventions::          Choosing appropriate names for keys and branches.
* File Attributes::             Marking files as executable, or other attributes.
* Migrating and Dumping::       Changing the underlying storage system.
* Importing from CVS::          Building a monotone database from a CVS repository.
* Exporting to GIT::            Building a git repository from a monotone database.
* Using packets::               Transferring data ``by hand''.
* Bisecting::                   Finding bad revisions.


File: monotone.info,  Node: Other Transports,  Next: Selectors,  Prev: Advanced Uses,  Up: Advanced Uses

3.1 Other Transports
====================

Monotone's database synchronization system is based on a protocol
called netsync. By default, monotone transports this protocol over a
plain TCP connection, but this is not the only transport monotone can
use. It can also transport netsync through SSH, or any program which
can provide a full-duplex connection over `stdio'.

   When a monotone client initiates a push, pull, or sync operation, it
parses the first command-line argument as a URI and calls a Lua hook to
convert that URI into a "connection command". If the Lua hook returns a
connection command, monotone spawns the command locally and speaks
netsync over a pipe connected to the command's standard I/O handles.

   If the Lua hook does not return a connection command, monotone
attempts to parse the command-line argument as a TCP address - a
hostname with an optional port number - connects a TCP socket the host
and port, and speaks netsync over the socket.

   By default, monotone understands two URI schemes:

  1. SSH URIs, of the form
     `ssh://[USER@]HOSTNAME[:PORT]/PATH/TO/DB.MTN',   to synchronize
     between private databases on hosts accessible only   through SSH.
     (These paths are absolute; to refer to a path relative   to a home
     directory, use   `ssh://HOST-PART/~/RELATIVE/PATH.MTN' or
     `ssh://HOST-PART/~USER/RELATIVE/PATH.MTN'.)

  2. File URIs, of the form   `file:/PATH/TO/DB.MTN', to synchronize
     between local databases.

   `ssh:' and `file:' are currently not supported on the native Win32
platform; they are supported on Cygwin and all other platforms.

   In the case of SSH URIs, the `ssh' program must be in your command
execution path, either $PATH on Unix-like systems or %PATH% on Windows
systems. Monotone will execute `ssh' as a subprocess, running `mtn
serve' on the other end of the SSH connection. You will need `mtn' to
be in the command execution path of the remote shell environment.

   In the case of File URIs, `mtn' is run locally, so must be in your
command execution path.

   In both cases, the database specified in the URI needs to exist
already, and will be locked for the duration of the synchronization
operation. Therefore, it must also be writable, even when monotone isn't
going to modify it, as it is the case for `pull'.  Also note that
monotone's default transport authentication is _disabled_ over these
transports, to reduce the complexity of configuration and eliminate
redundant protocol cost.

   Additional URI schemes can be supported by customization of the Lua
hooks `get_netsync_connect_command' and `use_transport_auth'. For
details on these hooks, see *note Netsync Transport Hooks::.


File: monotone.info,  Node: Selectors,  Next: Restrictions,  Prev: Other Transports,  Up: Advanced Uses

3.2 Selectors
=============

Revisions can be specified on the monotone command line, precisely, by
entering the entire 40-character hexadecimal SHA1 code. This can be
cumbersome, so monotone also allows a more general syntax called
"selectors" which is less precise but more "human friendly". Any
command which expects a precise revision ID can also accept a selector
in its place; in fact a revision ID is just a special type of selector
which is very precise.

Simple examples
===============

Some selector examples are helpful in clarifying the idea:

`a432'
     Revision IDs beginning with the string `a432'

`graydon@pobox.com/2004-04'
     Revisions written by `graydon@pobox.com' in April 2004.

`"jrh@example.org/2 weeks ago"'
     Revisions written by `jrh@example.org' 2 weeks ago.

`graydon/net.venge.monotone.win32/yesterday'
     Revisions in the `net.venge.monotone.win32' branch, written by
     `graydon', yesterday.

   A moment's examination reveals that these specifications are "fuzzy"
and indeed may return multiple values, or may be ambiguous. When
ambiguity arises, monotone will inform you that more detail is
required, and list various possibilities. The precise specification of
selectors follows.

Selectors in detail
===================

A selector is a combination of a selector type, which is a single ASCII
character, followed by a `:' character and a selector string. All
selectors strings except for selector type `c' are just values. The
value is matched against identifiers or certs, depending on its type,
in an attempt to match a single revision.  Selectors are matched as
prefixes. The current set of selection types are:

Generic cert selector
     Uses selector type `c'.  The selector string has the syntax NAME
     or NAME`='VALUE.  The former syntax will select any revision that
     has a cert with that name, regardless of value; the latter will
     match any revision that has a cert with that name and value.
     Values to match for can have shell wildcards.  For example,
     `c:tag' matches all revisions that have a tag, and
     `c:tag=monotone-0.25' will match the revision tagged
     `monotone-0.25'.  (See also the `t' selector below.)

Author selection
     Uses selector type `a'. For example, `a:graydon' matches `author'
     certs where the cert value contains `graydon'.

Key selection
     Uses selector type `k'. For example, `k:graydon@pobox.com' matches
     all revisions where at least one cert was signed by the key
     `graydon@pobox.com'.  Instead of the key's given name, the local
     name or the full hash ID of the key can be specified as well.

Branch selection
     Uses selector type `b'. For example, `b:net.venge.monotone' matches
     `branch' certs where the cert value is `net.venge.monotone'.
     Values to match for can have shell wildcards.  If you give a bare
     `b:' monotone will require you to be in a workspace, and will use
     the branch value recorded in your _MTN/options file.

Heads selection
     Uses selector type `h'. For example, `h:net.venge.monotone' matches
     `branch' certs where the cert value is `net.venge.monotone' and
     the associated revision is a head revision on that branch.  Values
     to match for can have shell wildcards like the branch selector.
     If you give a bare `h:' monotone will require you to be in a
     workspace, and use the branch recorded in your _MTN/options file.

Date selection
     Uses selector type `d'. For example, `d:2004-04' matches `date'
     certs where the cert value begins with `2004-04'. This selector
     also accepts expanded date syntax (see below).

Message selection
     Uses selector type `m'. For example `m:*foobar*' matches
     `changelog' and `comment' certs where the cert value contains the
     glob `*foobar*'.

"Earlier or equal than" selection
     Uses selector type `e'. For example, `e:2004-04-25' matches `date'
     certs where the cert value is less or equal than
     `2004-04-25T00:00:00'. If the time component is unspecified,
     monotone will assume 00:00:00. This selector also accepts expanded
     date syntax (see below)

"Later than" selection
     Uses selector type `l'. For example, `l:2004-04-25' matches `date'
     certs where the cert value is strictly greater than
     `2004-04-25T00:00:00'. If the time component is unspecified,
     monotone will assume 00:00:00. This selector also accepts expanded
     date syntax (see below)

Identifier selection
     Uses selector type `i'. For example, `i:0f3a' matches revision IDs
     which begin with `0f3a'.

Parent selection
     Uses selector type `p'. For example, `p:0f3a' matches the revision
     IDs which are the parent of the revision ID which begins with
     `0f3a'. If you give a bare `p:', monotone will require you to be in
     a workspace, and query the parent of the base workspace revision.

Update selection
     Uses selector type `u'. This selector must be used from within a
     workspace and must not have any associated value. It matches the
     base revision ID of the workspace before the last `update' command
     was executed. This can be useful for reviewing incoming revisions.
     After each update operation, or at least before the next update
     operation, run a command similar to the following:
          $ mtn log --to u: --diffs
     to log all revisions back to the last update. It can also be used
     for quickly jumping between two different revisions. For example,
     the following command:
          $ mtn update -r u:
     will update back to the previous update revision. Repeating this
     command will swap the current and previous update revision.

Tag selection
     Uses selector type `t'. For example, `t:monotone-0.11' matches
     `tag' certs where the cert value begins with `monotone-0.11'.
     Values to match for can have shell wildcards.

Workspace base revision
     Uses selector type `w'. This selector must be used from within a
     workspace and must not have any associated value. It matches the
     base revision ID(s) this workspace is based on.

   Further selector types may be added in the future.

Composite selectors
===================

Selectors may be combined with `and' and `or' operators and
parentheses, and may be modified using a function-call style syntax.
The recognized special characters are `/', `|', `;', `(' and `)', and
`\' (forward slash, pipe, semicolon, left and right parentheses, and
backslash); to use any of these characters in a selector value, precede
it with a backslash (`\').

   The `and' operator is the `/' character. For example, the selector
`a:graydon/d:2004-04' can be used to select a revision which has an
`author' cert beginning with `graydon' _as well as_ a `date' cert
beginning with `2004-04'.

   The `or' operator is the `|' character. For example, the selector
`h:some-feature-branch|h:other-feature-branch' can be used to select the
heads of two specific branches.

   There are also several selector functions defined, which take one or
more selectors as arguments. The general form for these is `name '('
selector [ ';' selector ... ] ')'', that is, arguments are enclosed in
parentheses and separated by semicolons. These are:
`difference(A;B)'
     Set difference; this returns all revisions selected by A but not
     by B. For example, `difference(a:graydon;b:net.venge.monotone)'
     would return all revisions which have an `author' cert beginning
     with `graydon' which are not in the branch `net.venge.monotone'.

`lca(A;B)'
     Least common ancestors; this is identical to
     `max((ancestors(A)|A)/(ancestors(B)|B))', but it may be faster and
     is certainly more convenient to type. For example,
     `lca(h:net.venge.monotone;h:net.venge.monotone.extended-selectors)'
     would return the last propagate between the given branches, or the
     branch point if there were no subsequent propagates yet. This
     could be particularly useful with the `diff' command, to see
     exactly what has changed on a given branch.

`max(A)'
     Erase ancestors; this returns all revisions selected by `A' which
     are not ancestors of other revisions selected by `A'. For example,
     `max(b:net.venge.monotone/a:graydon)' would return the latest
     revision(s) on branch `net.venge.monotone' which have an `author'
     cert beginning with `graydon'.

`ancestors(A)'
     Strict ancestors; returns all revisions which are an ancestor of a
     revision selected by `A'. For example,
     `ancestors(b:net.venge.monotone)' would return all revisions in
     branch `net.venge.monotone' except for the branch heads, and all
     revisions in branches which have been merged back into
     `net.venge.monotone'.

`descendants(A)'
     Strict descendants; returns all revisions which are a descendant
     of a revision selected by `A'. For example,
     `descendants(b:net.venge.monotone/a:graydon)' would return all
     revisions which are descended from a revision which is in branch
     `net.venge.monotone' and has an `author' cert beginning with
     `graydon'.

`parents(A)'
     Returns all revisions which are a parent of a revision selected by
     `A'.  For example, `parents(m:*foobar*)' would return the parents
     of any revisions which have `comment' or `changelog' certs
     containing the word `foobar'.

`children(A)'
     Returns all revisions which are a child of a revision selected by
     `A'.  For example, `children(m:*foobar*)' would return the
     children of any revisions which have `comment' or `changelog'
     certs containing the word `foobar'.

`pick(A)'
     Picks one of the revisions selected by `A', and returns that. For
     example, `h:some-branch' is often used with `mtn update', but will
     fail if `some-branch' has multiple heads. Using
     `pick(h:some-branch)' instead will always choose a single head,
     and not fail if there is more than one.

Selector expansion
==================

Before selectors are passed to the database, they are expanded using a
Lua hook: *note expand_selector::. The default definition of this hook
attempts to guess a number of common forms for selection, allowing you
to omit selector types in many cases. For example, the hook guesses
that the typeless selector `jrh@example.org' is an author selector, due
to its syntactic form, so modifies it to read `a:jrh@example.org'. This
hook will generally assign a selector type to values which "look like"
partial hex strings, email addresses, branch names, or date
specifications. For the complete source code of the hook, see *note
Default hooks::.

Expanding dates
===============

All date-related selectors (`d', `e', `l') support an English-like
syntax similar to CVS.  This syntax is expanded to the numeric format
by the Lua hook *note expand_date::.  The allowed date formats are:
`now'
     Expands to the current date and time.

`today'
     Expands to today's date. `e' and `l' selectors assume time 00:00:00

`yesterday'
     Expands to yesterday's date. `e' and `l' selectors assume time
     00:00:00

`<number> {minute|hour} <ago>'
     Expands to today date and time, minus the specified `number' of
     minutes|hours.

`<number> {day|week|month|year} <ago>'
     Expands to today date, minus the specified `number' of
     days|weeks|months|years. `e' and `l' selectors assume time 00:00:00

`<year>-<month>[-day[Thour:minute:second]]'
     Expands to the supplied year/month. The day and time component are
     optional. If missing, `e' and `l' selectors assume the first day
     of month and time 00:00:00.  The time component, if supplied, must
     be complete to the second.

Typeless selection
==================

If, after expansion, a selector still has no type, it is matched as a
special "unknown" selector type, which will match either a tag, an
author, or a branch. This costs slightly more database access, but
often permits simple selection using an author's login name and a date.
For example, the selector `graydon/net.venge.monotone.win32/yesterday'
would pass through the selector `graydon' as an unknown selector; so
long as there are no branches or tags beginning with the string
`graydon' this is just as effective as specifying `a:graydon'.


File: monotone.info,  Node: Restrictions,  Next: Scripting,  Prev: Selectors,  Up: Advanced Uses

3.3 Restrictions
================

Several monotone commands accept optional PATHNAME... arguments in
order to establish a "restriction".  Restrictions are used to limit the
files and directories these commands examine for changes when comparing
the workspace to the revision it is based on. Restricting a command to
a specified set of files or directories simply ignores changes to files
or directories not included by the restriction.

   The following commands all support restrictions using optional
PATHNAME... arguments:

   * `status'

   * `diff'

   * `revert'

   * `commit'

   * `list known'

   * `list unknown'

   * `list ignored'

   * `list missing'

   * `list changed'

   * `log'

   Including either the old or new name of a renamed file or directory
will cause both names to be included in a restriction. If in doubt, the
`status' command can be used to "test" a set of pathnames to ensure
that the expected files are included or excluded by a restriction.

   Commands which support restrictions also support the `--depth=N '
and `--exclude=PATH' options. The value N given to `--depth' specifies
the maximum number of directories to descend. For example, N=0 disables
recursion, N=1 means descend at most one directory below each specified
path, and so on.  The `--depth' value applies individually to each path
specified on the command line. The value PATH given to `--exclude'
specifies a path that should be excluded from the restriction. Multiple
`--exclude' options may be specified to exclude several files or
subdirectories.

   The `update' command does not allow for updates to a restricted set
of files, which may be slightly different than other version control
systems. Partial updates don't really make sense in monotone, as they
would leave the workspace based on a revision that doesn't exist in the
database, starting an entirely new line of development.

   In addition to including all of the explicitly specified paths and
excluding all of the paths specified with `--exclude' options a
restriction also implicitly includes the parent directories of all
included paths. This is done to allow commands operating on newly added
files to succeed. For example, if a new directory `a' is added and a
file `a/b' is added to this directory restricting to exactly `a/b' will
produce a meaningless state that doesn't include the required parent
directory `a'.

   The implicit inclusion of required parent directories is done for all
of the commands listed above with the exception of `revert'. This is
done to allow reverting the addition of files in newly added or renamed
directories without reverting the directories themselves. If the parent
directories were implicitly included their addition or name changes
would also be reverted.

Subdirectory restrictions
=========================

The restrictions facility also allows commands to operate from within a
subdirectory of the workspace.  By default, the entire workspace is
always examined for changes. However, specifying an explicit `.'
pathname to a command will restrict it to the current subdirectory.
Note that this is quite different from other version control systems
and may seem somewhat surprising.

   The expectation is that requiring a single `.' to restrict to the
current subdirectory should be simple to use. While the alternative,
defaulting to restricting to the current subdirectory, would require a
somewhat complicated `../../..' sequence to remove the restriction and
operate on the whole tree.

   This default was chosen because monotone versions whole project trees
and generally expects to commit all changes in the workspace as a
single atomic unit. Other version control systems often version
individual files or directories and may not support atomic commits at
all.

   When working from within a subdirectory of the workspace all paths
specified to monotone commands must be relative to the current
subdirectory.

Finding a workspace
===================

Monotone only stores a single `_MTN' directory at the root of a
workspace. Because of this, a search is done to find the `_MTN'
directory in case a command is executed from within a subdirectory of a
workspace. Before a command is executed, the search for a workspace
directory is done by traversing parent directories until an `_MTN'
directory is found or the filesystem root is reached. Upon finding an
`_MTN' directory, the `_MTN/options' file is read for default options.
The `--root' option may be used to stop the search early, before
reaching the root of the physical filesystem. The `--no-workspace'
option may be used to prevent the search entirely.

   Many monotone commands don't require a workspace and will simply
proceed with no default options if no `_MTN' directory is found.
However, some monotone commands do require a workspace and will fail if
no `_MTN' directory can be found.

   The `checkout', `clone' and `setup' commands create a new workspace
and initialize a new `_MTN/options' file based on their current option
settings.


File: monotone.info,  Node: Scripting,  Next: Inodeprints,  Prev: Restrictions,  Up: Advanced Uses

3.4 Scripting
=============

People often want to write programs that call monotone -- for example,
to create a graphical interface to monotone's functionality, or to
automate some task.  For most programs, if you want to do this sort of
thing, you just call the command line interface, and do some sort of
parsing of the output.  Monotone's output, however, is designed for
humans: it's localized, it tries to prompt the user with helpful
information depending on their request, if it detects that something
unusual is happening it may give different output in an attempt to make
this clear to the user, and so on.  As a result, it is not particularly
suitable for programs to parse.

   Rather than trying to design output to work for both humans and
computers, and serving neither audience well, we elected to create a
separate interface to make programmatically extracting information from
monotone easier.  The command line interface has a command `automate';
this command has subcommands that print various sorts of information on
standard output, in simple, consistent, and easily parseable form.

   For details of this interface, see *note Automation::.


File: monotone.info,  Node: Inodeprints,  Next: Merge Conflicts,  Prev: Scripting,  Up: Advanced Uses

3.5 Inodeprints
===============

Fairly often, in order to accomplish its job, monotone has to look at
your workspace and figure out what has been changed in it since your
last commit.  Commands that do this include `status', `diff', `update',
`commit', and others.  There are two different techniques it can use to
do this.  The default, which is sufficient for most projects, is to
simply read every file in the workspace, compute their SHA1 hash, and
compare them to the hashes monotone has stored.  This is very safe and
reliable, and turns out to be fast enough for most projects.  However,
on very large projects, ones whose source trees are many megabytes in
size, it can become unacceptably slow.

   The other technique, known as _inodeprints_, is designed for this
situation.  When running in inodeprints mode, monotone does not read the
whole workspace; rather, it keeps a cache of interesting information
about each file (its size, its last modification time, and so on), and
skips reading any file for which these values have not changed.  This is
inherently somewhat less safe, and, as mentioned above, unnecessary for
most projects, so it is disabled by default.

   If you do determine that it is necessary to use inodeprints with your
project, it is simple to enable them.  Simply run `mtn
refresh_inodeprints'; this will enable inodeprints mode and generate an
initial cache.  If you ever wish to turn them off again, simply delete
the file `_MTN/inodeprints'.  You can at any time delete or truncate
the `_MTN/inodeprints' file; monotone uses it only as a cache and will
continue to operate correctly.

   Normally, instead of enabling this up on a per-workspace basis, you
will want to simply define the `use_inodeprints' hook to return `true';
this will automatically enable inodeprints mode in any new workspaces
you create.  See *note Lua Reference:: for details.


File: monotone.info,  Node: Merge Conflicts,  Next: Workspace Collisions,  Prev: Inodeprints,  Up: Advanced Uses

3.6 Merge Conflicts
===================

Several different types of conflicts may be encountered when merging
two revisions using the database merge commands `merge',
`explicit_merge', `propagate' and `merge_into_dir' or when using the
workspace merge commands `update', `pluck' and `merge_into_workspace'.

   The `show_conflicts' and `automate show_conflicts' commands can be
used to list conflicts between database revisions which would be
encountered by the database merge commands.  Unfortunately, these
commands can't yet list conflicts between a database revision and the
current workspace.

   In addition, the `conflicts' set of commands can be used to specify
resolutions for some conflicts. The resolutions are stored in a file,
and given to the `merge' command via the
`--resolve-conflicts-file=filename' or `--resolve-conflicts' option;
see *note Conflicts::.

   The `merge' command normally will perform as many merges as
necessary to merge all current heads of a branch. However, when
`--resolve-conflicts-file' is given, the conflicts and their
resolutions apply only to the first merge, so the subsequent merges are
not done; the `merge' command must be repeated, possibly with new
conflicts and resolutions, to merge the remaining heads.

   For the special case of file content conflicts, a merge command
invoked without `--resolve-conflicts' will attempt to start an external
interactive merge tool; the user must then resolve the conflicts and
terminate the merge tool, letting monotone continue with the merge.
This process is repeated for each file content conflict. See *note File
Content Conflict:: below for more detail.

   For other conflicts, a merge command invoked without
`--resolve-conflicts' will fail.

   If `conflicts' supports resolving a particular conflict, that is the
simplest way to resolve it. Otherwise, resolving the different types of
conflicts is accomplished by checking out one of the conflicting
revisions, making changes as described below, committing these changes
as a new revision and then running the merge again using this new
revision as one of the merge parents. This process can be repeated as
necessary to get two revisions into a state where they will merge
cleanly.

   The possible conflict resolutions are discussed with each conflict in
the following sections.

3.6.1 Conflict Types
--------------------

Monotone versions files, directories, and file attributes explicitly,
and it tracks individual file and directory identity from birth to
death so that name changes throughout the full life-cycle can be
tracked exactly.  Partly because of these qualities, monotone notices
several types of conflicts that other version control systems may not.

   The two most common conflicts are described first, then all other
possible conflicts.

File Content Conflict
---------------------

This type of conflict is generally the one encountered most commonly
and represents conflicting changes made to lines of text within two
versions of a single file.

   When a merge command encounters changes in a file in both heads
relative to the common ancestor, it first checks to see if the file has
a `mtn:manual_merge' attribute with value `true'. If not, it uses an
internal merge algorithm to detect whether the changes are to the same
lines of the file. If they are not, monotone will use the result of the
internal merge as the new file version.

   `mtn:manual_merge' is set `true' when a file is `add'ed for all
files for which the `binary_file' hook returns true; see *note
attr_init_functions::.

   If `mtn:manual_merge' is present and `true', or if the changes are
to the same lines of the file, and neither `--resolve-conflicts' nor
`--non-interactive' was specified, the *note merge3:: hook is called,
with the content of both conflicting versions and their common ancestor.

   Alternatively, you can use your favorite merge tool asychronously
with the merge, and specify the result file in the conflicts file, using
the *note Conflicts:: command:
     mtn conflicts resolve_first user filename
   Then `--resolve-conflicts' is specified on the merge command line.

   Finally, rather than using a merge tool it is possible to commit
changes to one or both of the conflicting file versions so that they
will merge cleanly. This can also be a very helpful strategy if the
merge conflicts are due to sections of text in the file being moved
from one location to another. Rather than struggling to merge such
conflicting changes with a merge tool, similar rearrangements can be
made to one of the conflicting files before redoing the merge.

Duplicate Name Conflict
-----------------------

A duplicate name conflict occurs when two distinct files or directories
have been given the same name in the two merge parents.  This can occur
when each of the merge parents adds a new file or directory with the
conflicting name, or when one parent adds a new file or directory with
the conflicting name and the other renames an existing file or
directory to the conflicting name, or when both parents rename an
existing file or directory to the conflicting name.

   In earlier versions of monotone (before version 0.39) this type of
conflict was referred to as a _rename target conflict_ although it
doesn't necessarily have anything to do with renames.

   There are two main situations in which duplicate name conflicts
occur:

   * Two people both realize a new file should be added, and commit it.
     In this case, the files have the right name and the right
     contents, but monotone reports a conflict because they were added
     separately.

   * Two people each decide to add new files with different content, and
     accidently pick the same name.

   These conflicts are reported when someone tries to merge the two
revisions containing the new files.

   There are similar conflicts for directories; the process for
resolving them is different, because we need to worry about the files
in the directories.

Same file
.........

For the first case, the conflict is resolved by dropping one file. The
contents should be manually merged, in case they are slightly
different. Typically, a user will have one of the files in their
current workspace; the other can be retrieved via `automate
get_file_of'; the revision id is shown in the merge error message.

   This process can be confusing; here's a detailed example. We assume
the *note Conflicts:: commands are used to resolve this conflict, since
that is supported.

   Suppose Beth and Abe each commit a new file `checkout.sh', with
similar contents. When Beth attempts to merge the two heads, she gets a
message like:

     mtn: 2 heads on branch 'testbranch'
     mtn: [left]  ae94e6677b8e31692c67d98744dccf5fa9ccffe5
     mtn: [right] dfdf50b19fb971f502671b0cfa6d15d69a0d04bb
     mtn: conflict: duplicate name 'checkout.sh'
     mtn: added as a new file on the left
     mtn: added as a new file on the right
     mtn: error: merge failed due to unresolved conflicts

   The file labeled `right' is the file in Beth's workspace. To start
the conflict resolution process, Beth first saves the list of conflicts:

     mtn conflicts store

   In order to merge Beth's and Abe's file versions, Beth retrieves a
copy of Abe's file:

     mtn automate get_file_of checkout.sh \
     --revision=ae94e6677b8e31692c67d98744dccf5fa9ccffe5 \
     > _MTN/resolutions/checkout.sh-abe

   Now Beth manually merges (using her favorite merge tool)
`checkout.sh' and `_MTN/resolutions/checkout.sh-abe', leaving the
results in `_MTN/resolutions/checkout.sh-merge' (_not_ in her copy).

   Then Beth specifies the conflict resolution, and finishes the merge:

     mtn conflicts resolve_first_left drop
     mtn conflicts resolve_first_right user _MTN/resolutions/checkout.sh-merge
     mtn merge --resolve-conflicts-file=_MTN/conflicts
     mtn conflicts clean
     mtn update

   When Abe later syncs and updates, he will get the merged version.

Different files
...............

The second case, where two different files accidently have the same
name, is resolved by renaming one or both of them.

   Suppose Beth and Abe each start working on different thermostat
models (say Honeywell and Westinghouse), but they both name the file
`thermostat'. When Beth attempts to merge, she will get the same error
message as in the first case. When she retrieves Abe's file, she will
see that they should be different files. So she renames her file,
merges, and updates (again using *note Conflicts:: commands):

     mtn conflicts store
     mtn conflicts resolve_first_left rename thermostat-westinghouse
     mtn conflicts resolve_first_right rename thermostat-honeywell
     mtn merge --resolve-conflicts-file=_MTN/conflicts
     mtn conflicts clean
     mtn update

   Now she has her file contents in `thermostat-honeywell', and Abe's
in `thermostat-westinghouse'.

Directories
...........

When two directories are given the same name, there are still the two
basic approaches to resolving the conflict; drop or rename. However, if
a directory is dropped, all the files in it must also be dropped.
Therefore, it is almost always better to first rename one of the
directories to a temporary name as the conflict resolution, and then
deal with the files individually, renaming or merging and dropping
each. Then finally drop the temporary directory. The `conflicts'
commands do not support doing this; it must be done directly.

Missing Root Conflict
---------------------

Monotone's merge strategy is sometimes referred to as _die-die-die_
merge, with reference to the fact that when a file or directory is
deleted there is no means of resurrecting it. Merging the deletion of a
file or directory will _always_ result in that file or directory being
deleted.

   A missing root conflict occurs when some directory has been moved to
the root directory in one of the merge parents and has been deleted in
the other merge parent. Because of die-die-die merge the result will
not contain the directory that has been moved to the root.

   Missing root conflicts should be very rare because it is unlikely
that a project's root directory will change. It is even more unlikely
that a project's root directory will be changed to some other directory
in one merge parent and that this directory will also be deleted in the
other merge parent. Even still, a missing root directory conflict can
be easily resolved by moving another directory to the root in the merge
parent where the root directory was previously changed. Because of
die-die-die merge, no change to resolve the conflict can be made to the
merge parent that deleted the directory which was moved to the root in
the other merge parent.

   See the `pivot_root' command for more information on moving another
directory to the project root.

   `conflicts' does not yet support resolving this conflict.

Invalid Name Conflict
---------------------

Monotone reserves the name `_MTN' in a workspace root directory for
internal use and treats this name as _illegal_ for a versioned file or
directory in the project root. This name is _legal_ for a versioned
file or directory as long as it is not in the project root directory.

   An invalid name conflict occurs when some directory is moved to the
project root in one of the merge parents and a file or directory that
exists in this new root directory is renamed to `_MTN' or a new file or
directory is added with the name `_MTN' to this directory in the other
merge parent.

   Invalid name conflicts should be very rare because it is unlikely
that a project's root directory will change. It is even more unlikely
that a project's root directory will change and the new root directory
will contain a file or directory named `_MTN'. Even still, an invalid
name conflict can be easily resolved in several different ways. A
different root directory can be chosen, the offending `_MTN' file or
directory can be renamed or deleted, or it can be moved to some other
subdirectory in the project.

   See the `pivot_root' command for more information on moving another
directory to the project root.

   `conflicts' does not yet support resolving this conflict.

Directory Loop Conflict
-----------------------

A directory loop conflict occurs when one directory is moved under a
second in one of the merge parents and the second directory is moved
under the first in the other merge parent.

   Directory loop conflicts should be rare but can be easily resolved by
moving one of the conflicting directories out from under the other.

   `conflicts' does not yet support resolving this conflict.

Orphaned Node Conflict
----------------------

An orphaned node conflict occurs when a directory and all of its
contents are deleted in one of the merge parents and further files or
directories are added to this deleted directory, or renamed into it, in
the other merge parent.

   Orphaned node conflicts do happen occasionally but can be easily
resolved by renaming the orphaned files or directories out of the
directory that has been deleted and into another directory that exists
in both merge parents, or that has been added in the revision
containing the orphaned files or directories.

   `conflicts' supports resolving this conflict. However, if the
orphaned node is a directory that is not empty, and the desired
resolution is 'drop', the user must drop the directory contents and
commit before invoking the conflicts commands.

Multiple Name Conflict
----------------------

A multiple name conflict occurs when a single file or directory has
been renamed to two different names in the two merge parents.  Monotone
does not allow this and requires that each file and directory has
exactly one unique name.

   Multiple name conflicts do happen occasionally but can be easily
resolved by renaming the conflicting file or directory in one or both
of the merge parents so that both agree on the name.

   `conflicts' does not yet support resolving this conflict.

   In earlier versions of monotone (those before version 0.39) this type
of conflict was referred to as a _name conflict_.

Attribute Conflict
------------------

An attribute conflict occurs when a versioned attribute on a file or
directory is set to two different values by the two merge parents or if
one of the merge parents changes the attribute's value and the other
deletes the attribute entirely.

   Attribute conflicts may happen occasionally but can be easily
resolved by ensuring that the attribute is set to the same value or is
deleted in both of the merge parents. Attributes are _not_ merged using
the die-die-die rules and may be resurrected by simply setting their
values.

   `conflicts' does not yet support resolving this conflict.


File: monotone.info,  Node: Workspace Collisions,  Next: Quality Assurance,  Prev: Merge Conflicts,  Up: Advanced Uses

3.7 Workspace Collisions
========================

Workspace collisions can happen for many reasons; some examples include:
   * You have a file in your workspace that is unknown to monotone (you
     have not `add'ed it).  Someone else has `add'ed and `commit'ed a
     file with the same name.  If you try to `update' your workspace to
     their revision, the added file in the incoming revision will
     collide with your file.

   * There is a directory which contains both versioned and unversioned
     files (perhaps versioned sources, and unversioned object files
     built from the sources).  Someone else `commit's a revision that
     `drop's the versioned files _and_ the containing directory.  If
     you try to `update' to this revision, your directory will still
     contain the untracked files, and monotone will not delete them.

   * You have an unversioned file in your workspace, and you're trying
     to `update' to a revision that `add's a directory with the same
     name.

   These examples describe collisions on `update'; the same kinds of
things can happen with other commands that can bring changes into your
workspace, such as `checkout', `pivot_root' or `pluck'.

   In order to handle such collisions safely, before changing the
workspace, monotone will detect them, and the command will fail with a
warning.  The file content in the database is safe and can be recovered
at any time, so monotone is conservative and will refuse to destroy the
information in your workspace contents.

   In addition, all workspace-changing commands have an option
`--move-conflicting-paths', which moves unversioned but conflicting
files and directories from the workspace into a corresponding directory
under `_MTN/resolutions'. This is useful if you want to ensure that an
update always succeeds and you just want to move blocking paths out of
the way.

   However, monotone cannot detect all kinds of failures and collisions
in your workspace. For example:
   * On some systems with case-insensitive and/or internationalised
     filesystems, names that look distinct to monotone may in fact be
     considered the same by the underlying platform.

   * If some other program is creating files in the workspace at the
     same time as monotone, the colliding file might be created after
     the collision check at the start.

   * Other kinds of unpredictable system errors, like permissions
     problems or disk full conditions, might cause failures when
     monotone is rearranging the workspace content.

   These are all hopefully very rare occurrences. If such a filesystem
error _does_ cause a failure part-way during a workspace alteration,
monotone will stop immediately rather than risk potentially doing
further damage, and your workspace may be left in an incomplete state.
If this happens, you will need to resolve the issue and clean up the
workspace manually.  If you need to do so, understanding how monotone
manipulates the workspace is helpful.

   When monotone applies renaming changes to the workspace, each file is
first "detached" from the workspace under its old name, then "attached"
under the new name. This is done by moving it to the `_MTN/detached'
directory. Newly added files are created here before being moved into
place, too.  While inside `_MTN/detached', the file or directory is
named as a simple integer (monotone's internal identification of the
file node).  If the detached node is a directory, the directory is
moved with all of its contents (including unversioned files); this can
help identify which directory has been detached.

   If a previous workspace alteration failed part-way, the
`_MTN/detached' directory will still exist, and monotone will refuse to
attempt another alteration while the workspace is in this inconsistent
state. This also acts as a lock against multiple monotone processes
performing workspace alterations (but not other programs).

   The best way to avoid a messy recovery from such a failure is simply
to ensure that you always `commit' before trying to `update' (or
`pluck', etc) other changes from the database into your workspace. This
ensures that your current workspace contents are safely stored, and can
be retrieved later (such as with `revert').


File: monotone.info,  Node: Quality Assurance,  Next: Vars,  Prev: Workspace Collisions,  Up: Advanced Uses

3.8 Quality Assurance
=====================

Monotone was constructed to serve both as a version control tool and as
a quality assurance tool. The quality assurance features permit users
to ignore, or "filter out", versions which do not meet their criteria
for quality. This section describes the way monotone represents and
reasons about quality information.

   Monotone often views the collection of revisions as a directed graph,
in which revisions are the nodes and changes between revisions are the
edges. We call this the "revision graph". The revision graph has a
number of important subgraphs, many of which overlap. For example, each
branch is a subgraph of the revision graph, containing only the nodes
carrying a particular `branch' cert.

   Many of monotone's operations involve searching the revision graph
for the ancestors or descendants of a particular revision, or extracting
the "heads" of a subgraph, which is the subgraph's set of nodes with no
descendants. For example, when you run the `update' command, monotone
searches the subgraph consisting of descendants of the base revision of
the current workspace, trying to locate a unique head to update the
base revision to.

   Monotone's quality assurance mechanisms are mostly based on
restricting the subgraph each command operates on. There are two
methods used to restrict the subgraph:

   * By restricting the set of trusted `branch' certificates, you can
     require that specific code reviewers have approved of each edge in
     the subgraph you focus on.

   * By restricting the set of trusted `testresult' certificates, you
     can require that the _endpoints_ of an update operation have a
     certificate asserting that the revision in question passed a
     certain test, or testsuite.

   The evaluation of trust is done on a cert-by-cert basis by calling a
set of Lua hooks: *note get_revision_cert_trust::, *note
get_manifest_cert_trust::, and *note get_file_cert_trust::.  These
hooks are only called when a cert has at least one good signature from
a known key, and are passed _all_ the keys which have signed the cert,
as well as the cert's ID, name and value. The hook can then evaluate
the set of signers, as a group, and decide whether to grant or deny
trust to the assertion made by the cert.

   The evaluation of testresults is controlled by the
`accept_testresult_change' hook (see *note accept_testresult_change::).
This hook is called when selecting update candidates, and is passed a
pair of tables describing the `testresult' certs present on the source
and proposed destination of an update. Only if the change in test
results are deemed "acceptable" does monotone actually select an update
target to merge into your workspace.


File: monotone.info,  Node: Vars,  Next: Managed Databases,  Prev: Quality Assurance,  Up: Advanced Uses

3.9 Vars
========

Every monotone database has a set of _vars_ associated with it.  Vars
are simple configuration variables that monotone refers to in some
circumstances; they are used for configuration that monotone needs to be
able to modify itself, and that should be per-database (rather than
per-user or per-workspace, both of which are supported by `monotonerc'
scripts).  Vars are local to a database, and never transferred by
netsync.

   A var is a _name_ = _value_ pairing inside a _domain_.  Domains
define what the vars inside it are used for; for instance, one domain
might contain database-global settings, and particular vars inside it
would define things like that database's default netsync server.
Another domain might contain key fingerprints for servers that monotone
has interacted with in the past, to detect man-in-the-middle attacks;
the vars inside this domain would map server names to their
fingerprints.

   You can set vars with the `set' command, delete them with the
`unset' command, and see them with the `ls vars' command.  See the
documentation for these specific commands for more details.

Existing vars
=============

There are several pre-defined domains that monotone knows about:

`database'
     Contains database-global configuration information.  Defined names
     are:

    `default-include-pattern'
          The default global branch glob pattern for netsync operations
          to use.  Automatically set by first use of netsync, and by
          any netsync that uses the `--set-default' option.

    `default-exclude-pattern'
          The default global branch exclusion glob pattern for netsync
          operations to use. Automatically set by first use of netsync,
          and by any netsync that uses the `--set-default' option.

    `default-server'
          The default server for netsync operations to use.
          Automatically set by first use of netsync, and by any netsync
          that uses the `--set-default' option.

    `delta-direction'
          This tells monotone whether to store `reverse' deltas (the
          default), `forward' deltas, or `both' kinds of deltas for
          reconstructing versions of files. Reverse deltas are faster
          when inspecting recent files, while forward deltas are much
          faster for sending over the network. This should probably be
          set to `both' for a server database, unless disk space is
          severely limited. Note that as _receiving_ deltas involves
          reconstructing the file version that the delta was made
          against, a server using a database with only forward deltas
          will be somewhat slower at receiving new revisions unless
          your particular history graph is highly linear.

          Changing this value does not affect deltas that have already
          been stored.

    `known-workspaces'
          Records all registered workspaces for the current databases.
          monotone will track the contents of this variable
          automatically for you in the background.

`known-servers'
     Contains key hashes for servers that we have netsynced with in the
     past.  Analogous to `ssh''s `known_hosts' file, this is needed to
     detect man-in-the-middle attacks.  Automatically set the first
     time you netsync with any given server.  If that server's key later
     changes, monotone will notice, and refuse to connect until you
     have run `mtn unset known-servers SERVER-NAME'.

`server-include'
     Contains server-specific branch inclusion globs.  These overrule
     DEFAULT-INCLUDE-PATTERN if existant and are recorded automatically
     the first time you connect to a specific server or use the
     `--set-default' option for a netsync operation.

`server-exclude'
     Likewise, this variable contains server-specific branch exclusion
     globs, which overrule DEFAULT-EXCLUDE-PATTERN if existant and are
     also automatically set on the first connection or when the option
     `--set-default' is present.



File: monotone.info,  Node: Managed Databases,  Next: Reserved Files,  Prev: Vars,  Up: Advanced Uses

3.10 Managed Databases
======================

In monotone commands, a database name (provided to a `--db' option)
starting with ":" is a "database alias". It addresses a usual monotone
database sitting in a special, "managed" location, which we therefore
call a "managed database".

   The database alias is a regular file name (excluding the leading
colon).  Monotone searches for this file name in common locations and
internally expands it to a full path once it found an unambigious match.

   Some commands, such as `*note mtn clone::' and `*note mtn setup::',
work without a `--db' option; they fall back on a managed "default"
database and even initialize that in case it is not existant.

   To keep an overview of managed databases and their workspaces, the
commands `*note mtn list databases::' and `*note mtn list workspaces::'
can be used:  The former shows a list of all known databases in all
managed locations together with their workspaces, while the latter only
shows the list of workspaces for a single, specified database.

   Monotone usually keeps track of known workspaces automatically in the
background and updates the references as soon as your workspace'
database option in `_MTN/options' is set up or changed. There are a few
cases where monotone is unable to detect changes, though, for example
when a workspace is moved in the file system. To get monotone back on
track in cases like this, the commands `*note mtn register_workspace::'
and `*note mtn unregister_workspace::' can be used.

   Finally, all this magic behaviour can be customized by a variety of
lua hooks:

   * *note get_default_database_locations:: returns a list of search
     paths where monotone should look for managed databases.  This hook
     defaults to a single directory; `$HOME/.monotone/databases' on
     Unix and `%APPDATA%\monotone\databases' on Windows.

   * *note get_default_database_glob:: returns a pattern which monotone
     uses to match and recognized database files in the configured
     default locations.  This pattern is also used to determine if
     shortened database aliases, such as `:default', should get
     suffixed with `.mtn' to be transformed into a valid database file
     name. By default this hook returns `.{mtn,db}'.

   * *note get_default_database_alias:: returns the name of the alias
     of a default database that is initialized and used on demand.  If
     more than one database locations are configured, the first
     location is used as save location for this database. This hook
     defaults to `:default.mtn'.


File: monotone.info,  Node: Reserved Files,  Next: Reserved Certs,  Prev: Managed Databases,  Up: Advanced Uses

3.11 Reserved Files
===================

A monotone workspace consists of control files and non-control files.
Each type of file can be versioned or non-versioned. These
classifications lead to four groups of files:

   * versioned control files

   * non-versioned control files

   * versioned non-control files

   * non-versioned non-control files

   Control files contain special content formatted for use by monotone.
Versioned files are recorded in a monotone database and have their
state tracked as they are modified.

   If a control file is versioned, it is considered _part of_ the state
of the workspace, and will be recorded as a manifest entry. If a
control file is not versioned, it is used to _manage_ the state of the
workspace, but it not considered an intrinsic part of it.

   Most files you manage with monotone will be versioned non-control
files. For example, if you keep source code or documents in a monotone
database, they are versioned non-control files. Non-versioned,
non-control files in your workspace are generally temporary or junk
files, such as backups made by editors or object files made by
compilers. Such files are ignored by monotone.

Identifying control files
=========================

Control files are identified by their names. Non-control files can have
any name _except_ the names reserved for control files. The names of
control files follow a regular pattern:

Versioned control files
     Any file name beginning with `.mtn-'

Non-versioned control files
     Any file in the directory `_MTN/'

   The general intention is that versioned control files are things that
you may want to edit directly.  In comparison, you should never have to
edit non-versioned control files directly; monotone should do that for
you whenever it is appropriate.  However, both are documented here,
just in case a situation arises where you need to go "under the hood".

Existing control files and directories
======================================

The following control files are currently used. More control files may
be added in the future, but they will follow the patterns given above.

`.mtn-ignore'
     Contains a list of regular expression patterns, one per line. If
     it exists, any file with a name matching one of these patterns is
     ignored. *Note Regexps::, for the syntax of these regular
     expressions.

`_MTN/wanted-testresults'
     Contains a list of testresult key names, one per line. If it
     exists, update will only select revisions that do not have
     regressions according to the given testresult keys.

`_MTN/revision'
     Contains the identity of the "base" revision of the workspace, and
     a list of additions, deletions, and renames which have occurred in
     the current workspace, relative to that version.

     Every workspace has a base revision, which is the revision that was
     originally checked out to create that workspace.  When the
     workspace is committed, the base revision is considered to be the
     ancestor of the committed revision.

`_MTN/options'
     Contains "sticky" command-line options such as `--db' or
     `--branch', such that you do not need to enter them repeatedly
     after checking out a particular workspace.

`_MTN/log'
     Contains log messages to append to the "changelog" cert upon
     commit. The user may add content to this file while they work.
     Upon a successful commit monotone will empty the file making it
     ready for the next edit/commit cycle.

`_MTN/commit'
     If a commit fails, f.e. because a header field could not be parsed
     properly, then this file will contain a dump of the complete
     contents which have been saved through the editor.  After the
     information has been recovered from this file, it has to be
     removed explicitly, since a new commit won't be possible as long
     as this file exists.

`_MTN/inodeprints'
     If this file exists, monotone considers the directory to be in
     *note Inodeprints:: mode, and uses this file to cache the
     inodeprints.

`_MTN/debug'
     If monotone detects a bug in itself or crashes, then before
     exiting it dumps a log of its recent activity to this file, to aid
     in debugging.

`_MTN/bisect'
     Contains the current state of an ongoing bisection.  See *note
     Bisecting:: for more information.

`_MTN/update'
     Remembers the update / previous base revision of the workspace when
     the `u:' selector is used.  See *note Selectors:: for more
     information.

`_MTN/conflicts'
     The default file which is used by monotone to read and write merge
     conflicts for conflict resolution.  See *note Conflicts:: for more
     information.

`_MTN/resolutions'
     The directory in which monotone moves unversioned, conflicting
     files from a workspace to, in case `update' or other commands are
     called with the `--move-conflicting-paths' option.


File: monotone.info,  Node: Reserved Certs,  Next: Naming Conventions,  Prev: Reserved Files,  Up: Advanced Uses

3.12 Reserved Certs
===================

Every certificate has a name. Some names have meaning which is built in
to monotone, others may be used for customization by a particular user,
site, or community. If you wish to define custom certificates, you
should prefix such certificate names with `x-'. For example, if you
want to make a certificate describing the existence of security
vulnerabilities in a revision, you might wish to create a certificate
called `x-vulnerability'.  Monotone reserves all names which do not
begin with `x-' for possible internal use. If an `x-' certificate
becomes widely used, monotone will likely adopt it as a reserved cert
name and standardize its semantics.

   Most reserved certificate names have no meaning yet; some do. Usually
monotone is also responsible for _generating_ many of these certs as
part of normal operation, such as during a `commit'. Others will be
added explicitly via other commands, like `tag' or `approve'.

   As well as carrying other information, certs (and combinations of
certs) are useful for identifying revisions with *note Selectors::; in
particular, this is the primary purpose of the `tag' cert.

   The pre-defined, reserved certificate names are:

`author'
     This cert's value is the name of a person who committed the
     revision the cert is attached to. The cert is generated when you
     commit a revision. It is displayed by the `log' command.

`branch'
     This cert's value is the name of a branch. A `branch' cert
     associates a revision with a branch. The revision is said to be "in
     the branch" named by the cert. The cert is generated when you
     commit a revision, either directly with the `commit' command or
     indirectly with the `merge' or `propagate' commands. The `branch'
     certs are read and directly interpreted by _many_ monotone
     commands, and play a fundamental role in organizing work in any
     monotone database.

`changelog'
     This cert's value is the change log message you provide when you
     commit a revision. It is displayed by the `log' command.

`comment'
     This cert's value is an additional comment, usually provided after
     committing, about a revision. Certs with the name `comment' will be
     shown together with `changelog' certs by the `log' command.

`date'
     This cert's value is an ISO date string indicating the time at
     which a revision was committed. It is displayed by the `log'
     command, and may be used as an additional heuristic or selection
     criterion in other commands in the future.

`suspend'
     This cert's value is the name of a branch (see the `branch' cert).
     This cert is generated by the `suspend' command.  A suspended
     revision is removed from the list of head revisions of a branch in
     most cases.  A branch with all its heads suspended will not appear
     in the list of branches.  Suspended revisions can still have
     children, and those children are in no way affected by the suspend
     cert on their parent.

`tag'
     This cert's value is a symbolic name given to a revision, which
     may be used as a way of selecting the revision by name for later
     commands like `checkout', `log' or `diff'.

`testresult'
     This cert's value is interpreted as a boolean string, either `0'
     or `1'. It is generated by the `testresult' command and represents
     the results of running a particular test on the underlying
     revision. Typically you will make a separate signing key for each
     test you intend to run on revisions. This cert influences the
     `update' algorithm.



File: monotone.info,  Node: Naming Conventions,  Next: File Attributes,  Prev: Reserved Certs,  Up: Advanced Uses

3.13 Naming Conventions
=======================

Some names in monotone are private to your work, such as filenames.
Other names are potentially visible outside your project, such as RSA
key identifiers or branch names. It is possible that if you choose such
names carelessly, you will choose a name which someone else in the
world is using, and subsequently you may cause confusion when your work
and theirs is received simultaneously by some third party.

   We therefore recommend two naming conventions:

   * For RSA keys, use the name of an active email address you own.
     This will minimize conflicts, and also serves as a mnemonic to
     associate your personal _identity_ with signatures made with your
     key. For example, monotone's primary author uses the key identifier
     `graydon@pobox.com'.

   * For branch names, select any name you like but prefix it with the
     "inverted domain name" of a DNS domain you control or are otherwise
     authorized to use. This behavior mimics the package naming
     convention in the java programming language. For example, monotone
     itself is developed within the `net.venge.monotone' branch,
     because the original author owned the DNS domain `venge.net'.


File: monotone.info,  Node: File Attributes,  Next: Migrating and Dumping,  Prev: Naming Conventions,  Up: Advanced Uses

3.14 File Attributes
====================

Monotone contains a support for storing "persistent attributes" on
files and directories, generally known as "attrs" for short.  An attr
associates a simple name/value pair with a file or directory, and is
stored in the manifest.  Attrs are first-class versioned data; they can
be changed in a workspace, and those changes will be saved when the
workspace is committed.  The merger knows how to intelligently merge
attrs.

   The attribute mechanism was originally motivated by the fact that
some people like to store executable programs in version control
systems, and would like the programs to remain executable when they
check out a workspace.  For example, the `configure' shell script
commonly shipped with many programs should be executable.  Similarly,
some people would like to store devices, symbolic links, read-only
files, and all manner of extra attributes of a file, not directly
related to a file's data content.

   Monotone comes with support for some attrs built-in; for instance, if
an executable file is given to `mtn add', then it will automatically
mark the new file with a `mtn:execute' attr, and when the file is
checked out later, the executable bit will be set automatically.  (Of
course, if it is checked out on Windows, which does not support the
executable bit, then the executable bit will not be set.  However,
monotone will still know that the attr is set, and Windows users can
view and modify the attr like anyone else.)

   Attrs in the current workspace can be seen and modified using the
`*note mtn attr::' command.  Attrs can also be found by examining any
manifest directly.

   You can tell monotone to automatically take actions based on these
attributes by defining hooks; see *note attr_functions::.  Every time
your workspace is written to, monotone will run the corresponding hooks
registered for each attr in your workspace.  This way, you can extend
the vocabulary of attrs understood by monotone simply by writing new
hooks.

   You can make up your own attrs for anything you find useful; the
mechanism is fully general.  (If you make up some particularly useful
ones, we may even be interested in adding support to monotone proper.)
We only ask that if you do use custom attrs, you use some prefix for
them besides `mtn:'; attrs beginning with `mtn:' are reserved for
monotone's own use.


File: monotone.info,  Node: Migrating and Dumping,  Next: Importing from CVS,  Prev: File Attributes,  Up: Advanced Uses

3.15 Migrating and Dumping
==========================

While the state of your database is logically captured in terms of a
packet stream, it is sometimes necessary or desirable (especially while
monotone is still in active development) to modify the SQL table layout
or storage parameters of your version database, or to make backup
copies of your database in plain text. These issues are not properly
addressed by generating packet streams: instead, you must use
"migration" or "dumping" commands.

   The `mtn db migrate' command is used to alter the SQL schema of a
database. The schema of a monotone database is identified by a special
hash of its generating SQL, which is stored in the database's auxiliary
tables. Each version of monotone knows which schema version it is able
to work with, and it will refuse to operate on databases with different
schemas. When you run the `migrate' command, monotone looks in an
internal list of SQL logic which can be used to perform in-place
upgrades. It applies entries from this list, in order, attempting to
change the database it _has_ into the database it _wants_. Each step of
this migration is checked to ensure no errors occurred and the resulting
schema hashes to the intended value. The migration is attempted inside
a transaction, so if it fails -- for example if the result of migration
hashes to an unexpected value -- the migration is aborted.

   If more drastic changes to the underlying database are made, such as
changing the page size of SQLite, or if you simply want to keep a plain
text version of your database on hand, the `mtn db dump' command can
produce a plain ASCII SQL statement which generates the state of your
database. This dump can later be reloaded using the `mtn db load'
command.

   Note that when reloading a dumped database, the schema of the dumped
database is _included_ in the dump, so you should not try to `init'
your database before a `load'.


File: monotone.info,  Node: Importing from CVS,  Next: Exporting to GIT,  Prev: Migrating and Dumping,  Up: Advanced Uses

3.16 Importing from CVS
=======================

Monotone is capable of reading CVS files directly and importing them
into a database. This feature is still somewhat immature, but
moderately large "real world" CVS trees on the order of 1GB have
successfully been imported.

   Note however that the machine requirements for CVS trees of this size
are not trivial: it can take several hours on a modern system to
reconstruct the history of such a tree and calculate the millions of
cryptographic certificates involved. We recommend experimenting with
smaller trees first, to get a feel for the import process.

   We will assume certain values for this example which will differ in
your case:
   * Your domain name, `example.net' in this example.

   * Your key name, `import@example.net' in this example.

   * Your project name, `wobbler' in this example.

   * Your database name, `test.mtn' in this example.

   * Your CVS repository path, `/usr/local/cvsroot' in this example.

   * The CVS module name for your project, `wobbler' in this example.

   Accounting for these differences at your site, the following is an
example procedure for importing a CVS repository "from scratch", and
checking the resulting head version of the import out into a workspace:

     $ mtn --db=test.mtn db init
     $ mtn --db=test.mtn genkey import@example.net
     $ mtn --db=test.mtn --branch=net.example.wobbler cvs_import /usr/local/cvsroot/wobbler
     $ mtn --db=test.mtn --branch=net.example.wobbler checkout wobber-checkout


File: monotone.info,  Node: Exporting to GIT,  Next: Using packets,  Prev: Importing from CVS,  Up: Advanced Uses

3.17 Exporting to GIT
=====================

Monotone is capable of exporting the contents of a database to `stdout'
in a form suitable to be piped to git-fast-import(1):

     $ mkdir test.git
     $ cd test.git
     $ git init
     $ mtn --db test.mtn git_export | git fast import

   While this feature has been tested and verified to some extent with
various "real-world" monotone databases it is important to realize that
translating from one version control system to another can be a lossy
process. Git represents things somewhat differently than monotone does
and cannot fully represent some things that monotone can. In particular
git does not treat directories as first class objects as monotone does
and does not use certificates to represent `author', `date', `branch'
and `tag' values so some differences are to be expected.

   Git separates the concept of `committer' from the concept of
`author' while monotone allows multiple `author' certs. In an attempt
to represent these different concepts the git exporter uses the _value_
of the author cert as the git author and the _key_ used to sign the
author cert as the git committer. When there are multiple author certs
the git exporter arbitrarily choses one of them. The full list of
monotone certs may be exported in the git commit message using the
`--log-certs' option described in *note VCS::.

   Monotone author names often look like raw email addresses such as
`"user@example.com"'. These are not considered valid by git which
requires the display name and leading `<' and trailing `>' characters
around email addresses such as `"User Name <user@example.com>"'. The
git exporter deals with this difference in several ways:
   * revisions that don't have any author certs will default to using
     `Unknown <unknown>' for both the author and committer.

   * revisions that have one or more author certs will use the value of
     one author cert as the author and the key used to sign this cert as
     the committer.

   * both author and committer will be looked up in the file specified
     by the `--authors-file' option described in *note VCS:: and
     translated to the specified value if found.

   * any author or committer value not found in the authors file will be
     processed by the `unmapped_git_author' hook which may adjust the
     value so that it represents a valid value.
   All git author and committer values will be validated by the
`validate_git_author' hook before being written to the output stream.
The export will abort if any author or committer value is rejected by
the validation hook.

   Branch names used by monotone are allowed to contain characters that
are not considered valid by git. These may be mapped to other names
using the `--branches-file' option described in *note VCS::

   A monotone revision may have multiple `changelog' certs and multiple
`comment' certs. The git exporter deals with these by first
concatenating all of the changelog certs followed by all of the comment
certs into one message to use as the git commit message. Duplicate
changelog or comment cert messages that may exist due to automated
merges are removed.

   Exporting a database may be a time consuming and involved process,
depending on the size and nature of the database. A 200MB database
should export in less than an hour but may take several hours or longer
depending on factors such as hardware, revision sizes, roster sizes and
many others. The monotone process exporting such a database should
require less than 200MB of RAM but may require _considerably_ more in
some cases. If the exported file is written to disk it will likely be
_substantially_ larger than the associated database, perhaps between
400MB to 4GB in size.

   Anyone using the git exporter must take full responsibility for
verifying that the exported repository matches their expectations and
requirements.


File: monotone.info,  Node: Using packets,  Next: Bisecting,  Prev: Exporting to GIT,  Up: Advanced Uses

3.18 Using packets
==================

Suppose you made changes to your database, and want to send those
changes to someone else but for some reason you cannot use netsync.  Or
maybe you want to extract and inject individual revisions automatically
via an external program. In this case, you can convert the information
into packets. Packets are a convenient way to represent revisions and
other database contents as plain text with wrapped lines - just what
you need if you want to send them in the body of an email.

   This is a tutorial on how to transfer single revisions between
databases by dumping them from one database to a text file and then
reading the dump into a second database.

   We will create two databases, A and B, then create a few revisions in
A, and transfer part of them to B.

   First we initialize the databases:

     $ mtn -d A db init
     $ mtn -d B db init

   Now set up a branch in A:

     $ mtn -d A setup -b test test

   And let's put some revisions in that branch:

     $ cd test/
     $ cat > file
     xyz
     ^D
     $ mtn add file
     $ mtn ci -m "One"    You may need to select a key and type a passphrase here
     $ cat > file2
     file 2 getting in
     ^D
     $ cat > file
     ERASE
     ^D
     $ mtn add file2
     $ mtn ci -m "Two"
     $ cat > file
     THIRD
     ^D
     $ mtn ci -m "Three"

   OK, that's enough.  Let's see what we have:

     $ cd ..
     $ mtn -d A automate select i: | mtn -d A automate toposort -
     a423db0ad651c74e41ab2529eca6f17513ccf714
     d14e89582ad9030e1eb62f563c8721be02ca0b65
     151f1fb125f19ebe11eb8bfe3a5798fcbea4e736

   Three revisions! Let's transfer the first one to the database B.
First we get the meta-information on that revision:

     $ mtn -d A automate get_revision a423db0ad651c74e41ab2529eca6f17513ccf714
     format_version "1"

     new_manifest [b6dbdbbe0e7f41e44d9b72f9fe29b1f1a4f47f18]

     old_revision []

     add_dir ""

     add_file "file"
      content [8714e0ef31edb00e33683f575274379955b3526c]

   OK, one file was added in this revision. We'll transfer it. Now,
_ORDER MATTERS_!  We should transfer:

  1. The file data (fdata) and file deltas (fdeltas), if any

  2. The release data (rdata)

  3. The certs

   In that order. This is because certs make reference to release data,
and release data makes reference to file data and file deltas.

     mtn -d A automate packet_for_fdata 8714e0ef31edb00e33683f575274379955b3526c > PACKETS
     mtn -d A automate packet_for_rdata a423db0ad651c74e41ab2529eca6f17513ccf714 >> PACKETS
     mtn -d A automate packets_for_certs a423db0ad651c74e41ab2529eca6f17513ccf714 >> PACKETS
     mtn -d B read < PACKETS

   This revision (a423db0ad651c74e41ab2529eca6f17513ccf714) was already
sent to database B. You may want to check the PACKETS file to see what
the packets look like.

   Now let's transfer one more revision:

     mtn -d A automate get_revision d14e89582ad9030e1eb62f563c8721be02ca0b65
     format_version "1"

     new_manifest [48a03530005d46ed9c31c8f83ad96c4fa22b8b28]

     old_revision [a423db0ad651c74e41ab2529eca6f17513ccf714]

     add_file "file2"
      content [d2178687226560032947c1deacb39d16a16ea5c6]

     patch "file"
      from [8714e0ef31edb00e33683f575274379955b3526c]
        to [8b52d96d4fab6c1e56d6364b0a2673f4111b228e]

   From what we see, in this revision we have one new file and one
patch, so we do the same we did before for them:

     mtn -d A automate packet_for_fdata d2178687226560032947c1deacb39d16a16ea5c6 > PACKETS2
     mtn -d A automate packet_for_fdelta 8714e0ef31edb00e33683f575274379955b3526c 8b52d96d4fab6c1e56d6364b0a2673f4111b228e >> PACKETS2
     mtn -d A automate packet_for_rdata d14e89582ad9030e1eb62f563c8721be02ca0b65 >> PACKETS2
     mtn -d A automate packets_for_certs d14e89582ad9030e1eb62f563c8721be02ca0b65 >> PACKETS2
     mtn -d B read < PACKETS2

   Fine. The two revisions should be in the second database now.  Let's
take a look at what's in each database:

     $ mtn -d A automate select i: | mtn -d A automate toposort -
     a423db0ad651c74e41ab2529eca6f17513ccf714
     d14e89582ad9030e1eb62f563c8721be02ca0b65
     151f1fb125f19ebe11eb8bfe3a5798fcbea4e736

     $ mtn -d B automate select i: | mtn -d B automate toposort -
     a423db0ad651c74e41ab2529eca6f17513ccf714
     d14e89582ad9030e1eb62f563c8721be02ca0b65

   Good! B has the two first revisions (as expected), and A has all
three. However, a checkout of that branch on B will not work, because
the certificate signatures cannot be verified.  We need to transfer the
signatures too (suppose the key used had the ID `"johndoe@domain.com"'):

     mtn -d A pubkey johndoe@domain.com > KEY_PACKETS
     mtn -d B read < KEY_PACKETS

   Done.

     $ mtn -d B co -b test test-B
     $ ls test-B
     file2  _MTN  x
     $ more test-B/file2
     file 2 getting in

   And that's it! The revisions were successfully transferred.


File: monotone.info,  Node: Bisecting,  Prev: Using packets,  Up: Advanced Uses

3.19 Bisecting
==============

Bisecting is an efficient means of finding the earliest revision that
introduced a bug known to exist in some later revision. Given a set of
"good" earlier revisions that do not contain the bug and a set of "bad"
later revisions that do contain the bug `bisect' performs a binary
search over the set of revisions between these two sets to identify the
specific revision that introduced the bug.

   Bisection is started by marking revisions with the `bisect good' and
`bisect bad' commands. Once both good and bad revisions have been
specified the set of candidate revisions between the good and bad
revisions is determined. The midpoint of this set is selected as the
next revision to be tested and the workspace is updated to this
selected revision. After the selected revision has been tested
bisection continues when the revision is marked with `bisect good' or
`bisect bad'. If the selected revision is marked as good, it and all of
its ancestors are considered to be good and excluded from the remaining
search set. If the selected revision is marked as bad, all of its
descendants are considered to be bad and excluded from the remaining
search set. After each selected revision is marked as good or bad the
size of the remaining search set is halved.

   Revisions that are untestable for some reason (e.g. they don't
compile) may be ignored with the `bisect skip' command. This excludes
the specified revisions from the candidate set and allows the bisection
operation to continue. Skipping revisions may cause the search to fail
or end on the wrong revision if the revision being searched for is
skipped.

   If the workspace is updated to some unrelated revision during a
bisection operation the `bisect update' command can be used to update
back to the next revision selected for bisection. This command can also
be used if a previous `bisect good', `bisect bad' or `bisect skip'
command fails to update the workspace due to the existence of
conflicting unversioned paths.

   The current status of the bisection operation and the next revision
to be tested is reported by the `bisect status' command. This command
can be run at any stage of the bisection operation to see how many
revisions remain to be tested and how many revisions have been ruled
out.

   Currently `bisect' updates the workspace but does _not_ update the
workspace `branch' option. This may leave the workspace at a revision
that is _not_ in the branch specified by the workspace `branch' option
and cause subsequent commits to be made to the wrong branch. To help
avoid this error the `status' command will indicate when the workspace
branch does not match any of the parent revision branches. Take care
when committing new revisions during a bisection operation and be sure
to use the `bisect reset' command once the bisection is complete to
update the workspace back to the revision from which the bisection
started.

   The bisection operation completes successfully when the last
remaining revision is marked as "bad".  If the last remaining revision
is marked as "good" the bisection fails without finding the initial bad
revision.

   Once bisection is complete the workspace can be updated back to the
starting revision with the `bisect reset' command. This command also
removes all stored bisection information in preparation for future
bisect operations.


File: monotone.info,  Node: Command Reference,  Next: Formats,  Prev: Advanced Uses,  Up: Top

4 Command Reference
*******************

Monotone has a large number of commands. To help navigate through them
all, commands are grouped into logical categories. In addition, there
are global options that apply to all commands.

   Many command options come in pairs that affect the same value. For
example, `mtn log' takes a BRIEF option; this can be reversed by
NO-BRIEF. This is convenient when building command strings
automatically; `mtn log --brief --no-brief' is the same as `mtn log'.

   It also helps when setting options in the
GET_DEFAULT_COMMAND_OPTIONS hook; those options can be overridden on
the command line. For example, if GET_DEFAULT_COMMAND_OPTIONS specifies
BRIEF for `log', you can override that with `mtn log --no-brief'.

   Command names can be abbreviated to the shortest unique strings. Some
commands also have short aliases, such as `mv' for `rename'.

   The command descriptions describe the most important options for each
command, and only one of each pair of options. For a complete list of
options, see the online help (`mtn help cmd'), or the manpage.

   Many options can be specified by a single character; see the online
help for those.

   The Lua hook `*note get_default_command_options::' can change the
default value for any option.

   Revision arguments to commands may be selectors or hex ids.

* Menu:

* Global and Common Options::   Options that affect all or many commands
* Tree::                        Operations on tree states in your database
* Workspace::                   Operations on your workspace
* Network::                     Communication with the network
* Informative::                 Production of descriptive reports
* Review::                      Reviewing revisions
* Variables::                   Managing persistent variables
* Key and Cert::                Keys, Certificates
* Packet I/O::                  Production or consumption of packets
* Database::                    Manipulation of your database as a whole
* Automation::                  Running monotone from other programs
* VCS::                         Importing and exporting to other version control systems


File: monotone.info,  Node: Global and Common Options,  Next: Tree,  Prev: Command Reference,  Up: Command Reference

4.1 Global and Common Options
=============================

* Menu:

* Global Options::
* Common Options::


File: monotone.info,  Node: Global Options,  Next: Common Options,  Prev: Global and Common Options,  Up: Global and Common Options

4.1.1 Global Options
--------------------

These options are available on all commands.

`--confdir <arg>'
     Set the location of the configuration directory (default
     `$HOME/.monotone' on Unix and Cygwin, `%APPDATA%\monotone%' on
     Windows MinGW). In this manual, references to these specific
     directories are actually references to the directory specified by
     `--confdir'.

     The configuration directory is where monotone finds:

    `keys'
          in `confdir/keys'; see *note Certificates::, *note Generating
          Keys::. The location of the keys directory can be overridden
          separately with the `--keydir' option.

    `monotonerc'
          which is a per-user configuration file containing Lua code
          (see *note rcfiles::) that is run each time monotone starts
          up.

    `default database'
          In file `confdir/databases/default.mtn'; see *note Managed
          Databases::.


     In addition, monotone may write a dump file to the configuration
     directory when it fails (if it can't write to `_MTN' in a
     workspace).

`--date-format <arg>'
     `strftime(3)' format specification for printing dates. The default
     format is given by the `*note get_date_format_spec::' hook; the
     default hook returns `%x' for dates, `%X' for times, `%x %X' for
     both.

`--db <arg>'
     Set the database to use; defaults to the database specified in the
     current workspace (stored in `_MTN/options'; see *note Storage and
     workflow::), or to nothing if not in a workspace. However, some
     commands default to a *note Managed Databases::; that is specified
     in those commands.

     An argument of `:memory:' specifies a memory-only database; any
     changes are not saved to a file. One use for this is on the client
     side of a remote automate connection to the server, if you are
     executing commands that don't actually need a local database but
     the automate command requires one.

`--dump <arg>'
     File to dump debugging log to, on failure; default `confdir/dump'
     if not in a workspace, `_MTN/debug' if in a workspace.

`--help'
     Display help information. This is the same as the `mtn help'
     command, but note that it can be placed at the end of a command
     line, while `mtn help' must be the first non-option on the command
     line.

`--ignore-suspend-certs'
`--no-ignore-suspend-certs'
     Do not ignore revisions marked as suspended; see the `mtn suspend'
     command.

`--key <arg>'
`--use-default-key'
     Set the key for signatures or network authentication, using either
     the key name or the key hash (see *note Generating Keys::).

     monotone determines the key to use as follows:

       1. If `--key' is given, that is the key.

       2. If KEY is given in `_MTN/options', that is the key.

          Each time `--key' is given, it will be stored in
          `_MTN/options' for future use.

       3. For a non-netsync command, the Lua hook `*note
          get_branch_key::' is called.

          For a client-side netsync command, the Lua hook `*note
          get_netsync_client_key::' is called.

          For a command that starts a monotone server, the Lua hook
          `*note get_netsync_server_key::' is used.

          If any of the aforementioned hooks returns non-nil, the
          return value is the name of the key.

       4. If there is only one key in the keydir, that is the key.

       5. Otherwise there is no key; an error occurs.


`--keydir <arg>'
     Set the key directory (where the "key store" is located); default
     is `confir/keys'.

`--log <arg>'
     Specifiy a file to which the log (consisting of all debug,
     informational, and warning messages) is written; default is the
     `stderr' process output.

`--no-builtin-rcfile'
`--builtin-rcfile'
     Do not load the built-in rcfile with the default hooks. This means
     all hooks will have null definitions (unless overridden by other
     *note rcfiles::).

`--no-default-confdir'
`--allow-default-confdir'
     Don't use a default confdir; `--confdir' must be specified if a
     configuration file is needed.

`--no-format-dates'
     Don't use the format provided by a previous `--date-format', nor
     the format returned by `*note get_date_format_spec::'; instead,
     print dates in the format "yyyy-mm-ddThh:mm:ss".

`--[no-]standard-rcfiles'
     Do not load the standard rcfiles, which are
     `$HOME/.monotone/monotonerc' on Unix or
     `%APPDATA%\monotone\monotonerc' on Windows, and `_MTN/monotonerc'
     in the current workspace. See *note rcfiles::.

`--no-workspace'
`--allow-workspace'
     Don't look for a workspace; this means options that normally get
     their default values from the workspace will not have those
     default values.

`--non-interactive'
`--interactive'
     Do not prompt the user for input; fail instead. For example, don't
     prompt for a key passphrase, or when doing a merge, do not start
     the external merger to resolve a conflict.

`--quiet'
`--verbose'
     Decrease or increase verbosity. There are four levels of verbosity;
     debug, information, warning, and none. The default is information.

`--rcfile <arg>'
     Specify an extra rcfile to load. See *note rcfiles::.

`--clear-rcfiles'
     Cancel all previous `--rcfile' options (standard rcfiles are still
     loaded). See *note rcfiles::.

`--root <arg>'
     Limit the search for a workspace to the specified root directory

`--ssh-sign <arg>'
     Controls use of ssh-agent. Valid arguments are: 'yes' to use
     ssh-agent to make signatures if possible, 'no' to force use of
     monotone's internal code, 'only' to force use of ssh-agent,
     'check' to sign with both and compare.

`--ticker <arg>'
     Set ticker style; one of 'count', 'dot', or 'none'

`--timestamps'
     Show timestamps in front of error, warning, and progress messages.

`--version'
     Print version number, then exit; same as `mtn version'.

`--xargs <arg>'
`-@ <arg>'
     Insert command line arguments taken from the given file.


File: monotone.info,  Node: Common Options,  Prev: Global Options,  Up: Global and Common Options

4.1.2 Common Options
--------------------

These options are available on many commands.
`--author'
     Override the author cert for a commit; normally, the author is the
     local name of the key used for the commit. See `*note
     get_author::', `*note --key::', `*note get_local_key_name::'.

`--branch'
     Specify the branch for a command. This normally defaults to the
     workspace branch.

`--date'
     Override the date cert for a commit. The date defaults to the
     current calendar time.

`--message STRING'
     Set the commit changelog message, as a string. Each command that
     does a commit has a different default for the message.

`--message-file FILENAME'
     Set the commit changelog message, as a file. Each command that does
     a commit has a different default for the message.

`--[no-]update'
     If `--update' is given, and the command is executed in a
     workspace, the workspace is updated to the new head of the
     workspace branch if the workspace was at a head, and the command
     makes a new head of the workspace branch.



File: monotone.info,  Node: Tree,  Next: Workspace,  Prev: Global and Common Options,  Up: Command Reference

4.2 Tree
========

`mtn checkout [--[no-]move-conflicting-paths] --revision=ID DIRECTORY'
`mtn checkout [--[no-]move-conflicting-paths] --branch=BRANCHNAME DIRECTORY'
`mtn co'
     `co' is an alias for `checkout'

     These commands copy a revision ID out of your database, recording
     the chosen revision (the "base revision") in the file
     `DIRECTORY/_MTN/revision'. These commands then copy every file
     version listed in the revision's manifest to paths under DIRECTORY.

     For example, if the revision's manifest contains these entries:

          dir ""

             file "Makefile"
          content [84e2c30a2571bd627918deee1e6613d34e64a29e]

             file "include/hello.h"
          content [c61af2e67eb9b81e46357bb3c409a9a53a7cdfc6]

             file "src/hello.c"
          content [97dfc6fd4f486df95868d85b4b81197014ae2a84]

     Then the following files are created:
          DIRECTORY/
          DIRECTORY/Makefile
          DIRECTORY/include/hello.h
          DIRECTORY/src/hello.c

     If you wish to `checkout' in the current directory, you can supply
     the special name `.' (a single period) for DIRECTORY. When running
     `checkout' into an existing directory, it is sometimes possible
     for *note Workspace Collisions:: to occur.

     If no ID is provided, as in the latter two commands, you _must_
     provide a BRANCHNAME; monotone will attempt to infer ID as the
     unique head of BRANCHNAME if it exists.

`mtn conflicts'
     See *note Conflicts::

`mtn explicit_merge [--[no-]update] ID ID DESTBRANCH'
     See the online help for options. See *note --update::.

     This command merges exactly the two IDs you give it, and places
     the result in branch DESTBRANCH.  It is useful when you need more
     control over the merging process than `propagate' or `merge' give
     you.  For instance, if you have a branch with three heads, and you
     only want to merge two of them, you can use this command.  Or if
     you have a branch with two heads, and you want to propagate one of
     them to another branch, again, you can use this command.

     *note Merge Conflicts:: can occur.

`mtn heads [--branch=BRANCHNAME]'
     This command lists the "heads" of BRANCHNAME (defaults to the
     current workspace).

     The "heads" of a branch is the set of revisions which are members
     of the branch, but which have no descendants. These revisions are
     generally the "newest" revisions committed by you or your
     colleagues, at least in terms of ancestry. The heads of a branch
     may not be the newest revisions, in terms of time, but
     synchronization of computer clocks is not reliable, so monotone
     usually ignores time.

`mtn import --branch=BRANCH [--message=MESSAGE] [--[no-]dry-run] DIR'
`mtn import --revision=REVISION [--message=MESSAGE] [--[no-]dry-run] DIR'
     See the online help for more options.

     This command imports the contents of the given directory and
     commits it to the head of the given branch or as a child of the
     given revision (and consequently into the branch that revision
     resides in).

     If the given branch doesn't exist, it is created automatically.
     If the branch already exists, any missing files are dropped and
     any unknown files are added before committing.

     If neither `--message' nor `--message-file' is given, the Lua hook
     `*note edit_comment::' is called to provide a commit comment, with
     text formatted as in `*note mtn commit::'.

     If `--dry-run' is given, no commit is done.

     Roughly speaking, `mtn import' does the following:

          $ mtn setup (with a twist)
          $ mtn drop --missing
          $ mtn add --unknown
          $ mtn commit

     The twist with the `mtn setup' part is that it sets the parent to
     be the given revision or the head of the given branch instead of
     the null revision.

`mtn merge [--branch=BRANCHNAME] [--message STRING] [--message-file FILENAME] [--[no-]update]'
     See the online help for more options. See *note --update::.

     This command merges the "heads" of BRANCHNAME (default the branch
     of the current workspace), if there are multiple heads, and
     commits the results to the database, marking the resulting merged
     revision as a member of BRANCHNAME. The merged revision will
     contain each of the head revision IDs as ancestors.

     A commit message may be provided via `--message STRING' or
     `--message-file FILENAME'. A message stating the revision ids that
     were merged will be prepended to any user commit message.

     Merging is performed by repeated pairwise merges: two heads are
     selected, then their least common ancestor is located in the
     ancestry graph and these 3 revisions are provided to the built-in
     3-way merge algorithm. The process then repeats for each
     additional head, using the result of each previous merge as an
     input to the next.

     *note Merge Conflicts:: can occur.

`mtn merge_into_dir [--[no-]update] SOURCEBRANCH DESTBRANCH DIR'
     This command takes a unique head from SOURCEBRANCH and merges it
     into a unique head of DESTBRANCH, as a directory. The resulting
     revision is committed to DESTBRANCH. If either SOURCEBRANCH or
     DESTBRANCH has multiple heads, `merge_into_dir' aborts, doing
     nothing.

     The purpose of `merge_into_dir' is to permit a project to contain
     another project in such a way that `propagate' can be used to keep
     the contained project up-to-date. It is meant to replace the use
     of nested checkouts in many circumstances.

     Note that `merge_into_dir' _does not_ permit changes made to the
     contained project in DESTBRANCH to be propagated back to
     SOURCEBRANCH. Attempting this would lead to SOURCEBRANCH containing
     both projects nested as in DESTBRANCH instead of only the project
     originally in SOURCEBRANCH, which is almost certainly not what
     would be intended.

     *note Merge Conflicts:: can occur. See *note --update::.

`mtn merge_into_workspace [--[no]-move-conflicting-paths] REVISION'
     Merges REVISION into the current workspace; the result is not
     committed to the database. There can be no pending changes in the
     current workspace. The workspace's selected branch is not changed.

     When a later commit is done, both REVISION and the workspace's
     base revision will be recorded as parents.

     *note Merge Conflicts:: and *note Workspace Collisions:: can occur.

`mtn migrate_workspace [DIRECTORY]'
     Migrates a workspace directory's metadata to the latest format.

     If no directory is given, defaults to the current workspace.

     This may be needed when upgrading to a new version of monotone.

`mtn propagate SOURCEBRANCH DESTBRANCH [--message STRING] [--message-file FILENAME]'
     See online help for more options. See *note Common Options::.

     This command takes a unique head from SOURCEBRANCH and merges it
     with a unique head of DESTBRANCH, using the least common ancestor
     of the two heads for a 3-way merge. The resulting revision is
     committed to DESTBRANCH. If either SOURCEBRANCH or DESTBRANCH has
     multiple heads, `propagate' aborts, doing nothing.

     A commit message may be provided via `--message STRING' or
     `--message-file FILENAME'. A message stating the source and target
     branches will be prepended to any user commit message.

     The purpose of `propagate' is to copy all the changes on
     SOURCEBRANCH, since the last `propagate', to DESTBRANCH. This
     command supports the idea of making separate branches for
     medium-length development activities, such as maintenance branches
     for stable software releases, trivial bug fix branches, public
     contribution branches, or branches devoted to the development of a
     single module within a larger project.

     *note Merge Conflicts:: can occur.

`mtn refresh_inodeprints'
     This command puts the current workspace into *note Inodeprints::
     mode, if it was not already, and forces a full inodeprints cache
     refresh.  After running this command, you are guaranteed that your
     workspace is in inodeprints mode, and that the inodeprints cache
     is accurate and up to date.

`mtn setup --branch BRANCHNAME [--db DATABASE] [DIRECTORY]'
     This command prepares DIRECTORY (default current directory) as a
     monotone workspace, by creating and populating the `_MTN'
     directory with basic information.

     If no database is given, the configured default database is
     created or re-used (see *note get_default_database_alias:: for
     more details).  Both settings, branch and database name, will be
     placed in the `_MTN/options' file.

     This can be used with an empty directory to start a new blank
     project, or within an existing directory full of files, prior to
     using `mtn commit'.


* Menu:

* Conflicts::


File: monotone.info,  Node: Conflicts,  Prev: Tree,  Up: Tree

4.2.1 Conflicts
---------------

The `conflicts' set of commands is used to specify conflict resolutions
for merges, asynchronously from the merge command itself.  This lets
the user take as much time as needed to prepare all the conflict
resolutions, and avoids losing work when a merge is aborted due to a
complicated conflict. See *note Merge Conflicts::.

   These commands require a workspace, to provide a place to store the
conflicts and user resolution files.

   For all of these commands, if the `--conflicts-file' option is not
given, the file `_MTN/conflicts' is used. If the `--conflicts-file'
option is given, the file must be in the bookkeeping directory.

   Files given in these commands are relative to the current working
directory, or absolute. In the conflict file, they are relative to the
workspace root, or absolute.

   The commands are listed in the order they are typically used, not in
alphabetical order. Then the conflict resolutions are discussed.

Commands
--------

`mtn conflicts store [--conflicts-file=FILE] [LEFT_REV_ID RIGHT_REV_ID]'
     Store the conflicts encountered by merging LEFT_REV_ID with
     RIGHT_REV_ID, in the specified file (defaults to `_MTN/conflicts'.
     If LEFT_REV_ID and RIGHT_REV_ID are not given, the first two heads
     that the `merge' command would merge are used.

     The conflicts file format is as output by the `automate
     show_conflicts' command; see `*note mtn automate show_conflicts::'.

     Content conflicts that can be resolved by the internal line merger
     have resolutions, so they will not show up in subsequent
     `show_first' commands.

`mtn conflicts show_first [--conflicts-file=FILE]'
     Show the first unresolved conflict in the conflicts file, and list
     the possible resolutions.

`mtn conflicts show_remaining [--conflicts-file=FILE]'
     Show remaining unresolved conflicts in the conflicts file.

`mtn conflicts resolve_first [--conflicts-file=FILE] RESOLUTION'
     Specify a resolution for the first conflict in the conflicts file;
     it must be a single file conflict. The conflicts file is updated.

`mtn conflicts resolve_first_left [--conflicts-file=FILE] RESOLUTION'
`mtn conflicts resolve_first_right [--conflicts-file=FILE] RESOLUTION'
     Specify a resolution for one of the files in the first conflict in
     the conflicts file; it must be a two file conflict. The conflicts
     file is updated.

`mtn conflicts clean'
     Delete the default conflicts file `_MTN/conflicts', and the
     directory `_MTN/resolutions'. Users may store conflict resolution
     files in `_MTN/resolutions'; this command provides a convenient
     way to clean up.

Single file conflict resolutions
--------------------------------

For single file conflicts, there are several possible resolutions. Note
that `resolved_user_left' is used even for single file conflicts.

`interactive [FILE]'
     The Lua *note merge3:: hook is called to allow the user to manually
     merge the left and right files, leaving the result in the
     specified file.

     FILE must be a bookkeeping path; under `_MTN'. If not specified,
     FILE defaults to `_MTN/resolutions/<path>', where `<path>' is the
     path to the file that has the conflict.

     This inserts a `resolved_user_left FILE' conflict resolution in the
     conflicts file.

`user FILE'
     The file contents are replaced by the contents of the specified
     file.

     This inserts a `resolved_user_left FILE' conflict resolution in the
     conflicts file.

`drop'
     The file is dropped in the merge. This is useful for an orphaned
     file conflict.

     This inserts a `resolved_drop_left' conflict resolution in the
     conflicts file.

`rename FILENAME'
     The file is renamed. This is useful for an orphaned file conflict.

     This inserts a `resolved_rename_left FILENAME' conflict resolution
     in the conflicts file.


Two file conflict resolutions
-----------------------------

For two file conflicts, the possible resolutions are:

`drop'
     The file is dropped in the merge.

     This inserts a `resolved_drop_left' or `resolved_drop_right'
     conflict resolution in the conflicts file.

`keep'
     The file is kept in the merge.

     This inserts a `resolved_keep_left' or `resolved_keep_right'
     conflict resolution in the conflicts file.

`rename FILENAME'
     The file is renamed.

     This inserts a `resolved_rename_left FILENAME' or
     `resolved_rename_right FILENAME' conflict resolution in the
     conflicts file.

`user FILE'
     The file contents are replaced by the contents of the specified
     file.  The other file in the conflict must be dropped or renamed.

     This inserts a `resolved_user_left FILE' or `resolved_user_right
     FILE' conflict resolution in the conflicts file.


   monotone internals note: we don't provide an `interactive'
resolution for two-file conflicts, because monotone currently does not
provide a `merge2' Lua hook. two-file conflicts don't have a shared
ancestor, so `merge3' is not applicable.


File: monotone.info,  Node: Workspace,  Next: Network,  Prev: Tree,  Up: Command Reference

4.3 Workspace
=============

`mtn add [--[no-]recursive] [--[no-]respect-ignore] PATHNAME...'
`mtn add [--[no-]recursive] [--[no-]respect-ignore] --[no-]unknown [PATHNAME...]'
     This command places `add' entries for the paths specified in
     PATHNAME... in *note _MTN/revision::; they will be part of the
     next `commit'. See *note Storage and workflow:: for more
     information on `add' and `commit'.

     As a convenience, the `--unknown PATHNAME...' option can be used;
     this option will cause all of the files listed by `mtn list
     unknown PATHNAME...' to be added.

     Adding directories, whether explicitly or using the `--unknown'
     option, is non-recursive by default.  The `add' command can be
     made recursive using the `--recursive' option.  When adding a
     directory non-recursively, monotone will warn if the directory has
     any files that would be added by a recursive add.

`mtn attr'
     Manage *note File Attributes::.

     In `drop' and `get', if no attribute is specified, the command
     applies to all attributes attached to the file given in PATH.
     Otherwise it applies only to the attribute specified in ATTR.

    `mtn attr drop PATH [ATTR]'
          Remove attributes.

    `mtn attr get PATH [ATTR]'
          Output the attributes.

    `mtn attr set PATH ATTR VALUE'
          Sets ATTR on PATH to VALUE.


`mtn commit'
`mtn commit --message=LOGMSG [--message=LOGMSG...] [PATHNAME...]'
`mtn commit --message-file=LOGFILE [PATHNAME...]'
`mtn ci'
     `ci' is an alias for `commit'. See the online help for more
     options.

     This command looks at your workspace, decides which files have
     changed, and saves the changes to your database. It works by
     loading the revision named in *note _MTN/revision::, locating the
     base manifest for your workspace, applying any pathname changes
     described, and then comparing the updated base manifest to the
     files it finds in your workspace, to determine which files have
     been edited.

     For each edited file, a delta is copied into the database. Then the
     newly constructed manifest is recorded (as a delta) and finally the
     new revision.  Once all these objects are recorded in your
     database, `commit' updates `_MTN/revision' to indicate that the
     base revision is now the newly created revision, and that there
     are no pathname changes to apply.

     Specifying pathnames to `commit' restricts the set of changes that
     are visible and results in only a partial commit of the workspace.
     Changes to files not included in the specified set of pathnames
     will be ignored and will remain in the workspace until they are
     included in a future commit. With a partial commit, only the
     relevant entries in `_MTN/revision' will be removed and other
     entries will remain for future commits.

     From within a subdirectory of the workspace the `commit' command
     will, by default, include _all changes_ in the workspace.
     Specifying only the pathname "." will restrict `commit' to files
     changed within the current subdirectory of the workspace.

     The `--message' and `--message-file' options are mutually
     exclusive.  Both provide a LOGMSG describing the commit.
     `--message-file' specifies the name of the file containing the log
     message, while `--message' provides it directly.

     Multiple `--message' options may be provided on the command line.
     The log message will be formed by concatenating the `--message'
     options provided, with each one starting at the beginning of a new
     line.

     If neither `--message-file' nor `--message' are given, the commit
     message defaults to the contents of `_MTN/log', after processing
     by the Lua hook *note edit_comment::. `_MTN/log' can be edited by
     the user during their daily work to record the changes made to the
     workspace.

     The default definition of `edit_comment' invokes the user's editor
     (specified by the environment variables `VISUAL' and `EDITOR', or
     `editor, vi', or `notepad' on Windows).

     `commit' formats the input to `edit_comment' as follows:

          <contents of _MTN/log>

          *** REMOVE THIS LINE TO CANCEL THE COMMIT ***
          -- Enter a description of this change above --
          -- Edit fields below to modify certificate values --
          Branch:    <from _MTN/options or option>
          Author:    <from key or option>
          Date:      <from system clock>

          -- Modifications below this line are ignored --
          Changes against parent <from _MTN/revision>

            <list of changes>
     When the user quits the editor, the text is processed as follows:

        * The final LOGMSG is all text up to the line "*** REMOVE THIS
          LINE ..." (the "cancel" line).

        * If the LOGMSG is empty, the commit is aborted.

        * If the cancel line is deleted or modified, the edited LOGMSG
          is saved in `_MTN/log', and the commit is aborted.

        * The next two lines (instructions) are confirmed to be
          present. If not, the commit is aborted, and the entire file
          is saved in `_MTN/commit', so the user may recover.

        * The "Branch", "Author", and "Date" fields are parsed, and the
          new values used for the commit. If the parsing fails, the
          commit is aborted, and the entire file is saved in
          `_MTN/commit', so the user may recover.

          The date is formatted with the spec provided by
          `--date-format' or Lua hook `*note get_date_format_spec::'.
          When the date field is parsed, the same spec is used.
          Therefore this spec must be supported by the operating system
          function for parsing dates; if not, the monotone internal
          format of "yyyy-mm-ddThh:mm:ss" is used for both formatting
          and parsing.

        * The rest of the text is ignored.

     If the commit is successful, the `_MTN/log' file is cleared of all
     content making it ready for another edit/commit cycle.

     As a special case, if `--message-file=_MTN/log' is specified, the
     contents of `_MTN/log' will be used without first invoking
     `edit_comment'.

     If a `--branch' option is specified, the `commit' command commits
     to this branch (creating it if necessary).  The branch becomes the
     new default branch of the workspace.

     The `commit' command also synthesizes a number of certificates,
     which it attaches to the new manifest version and copies into your
     database:
        * An `author' cert, indicating the person responsible for the
          changes leading to the new revision.  Normally this defaults
          to your signing key or the return value of the *note
          get_author:: hook; you may override this by passing the
          `--author' option to commit, or by editing the "Author" field
          in your editor.  This is useful when committing a patch on
          behalf of someone else, or when importing "by hand" from
          another version control system.

        * A `branch' cert, indicating the branch the committed revision
          belongs to.

        * A `date' cert, indicating when the new revision was created.
          Normally this defaults to the current date and time; you may
          override this by passing the `--date' option to commit, or by
          editing the "Date" field in your editor.  This is useful when
          importing "by hand" from another version control system.

        * A `changelog' cert, containing the LOGMSG.


`mtn drop [--[no]-recursive] [--bookkeep-only] PATHNAME...'
`mtn drop --missing PATHNAME...'
`mtn rm'
     `rm' is an alias for `drop'.

     This command places "drop" entries for the paths specified in
     PATHNAME... in *note _MTN/revision:: and deletes the file from the
     workspace. This will be part of the next `commit'. If any of
     PATHNAME... is a directory, and `--recursive' is not given, and
     the directory contains any versioned files, the command will fail.
     If `--recursive' is given, the versioned files will be dropped. If
     the directory contains unversioned files, it will be dropped from
     the revision, but not deleted from the disk.

     If `--missing' is given, `drop' will add drop entries for any
     versioned paths in PATHNAME... for which you have already removed
     the files from the filesystem.

     This command also removes any attributes on PATHNAME; see *note
     File Attributes:: for more details.

     If `--bookkeep-only' is given, or if a file is different from the
     version in the base revision, `drop' will drop remove PATHNAME...
     from the revision at commit time, but _not_ remove the file from
     the workspace.

     See the `undrop' command for undoing a `drop' before commit.

`mtn mkdir [--[no-]respect-ignore] DIRECTORY...'
     This command creates directories in the filesystem relative to your
     current location and adds them to *note _MTN/revision::.  This
     will be part of the next `commit'.

     Normally, if any of DIRECTORY... are in `.mtn-ignore', this
     command will fail. You can use `--no-respect-ignore' to override
     this check. But it would be better to remove DIRECTORY from
     `.mtn-ignore'.

`mtn pivot_root [--bookkeep-only] [--[no-]move-conflicting-paths] NEW_ROOT PUT_OLD'
     Most users will never need this command.  It is primarily useful in
     certain tricky cases where one wishes to combine several projects
     into one, or split one project into several. See also
     `merge_into_dir'.

     Its effect is to rename the directory whose name is currently
     NEW_ROOT to become the root directory of the versioned tree, and
     to at the same time rename the directory that is currently the
     root of the versioned tree to have the name PUT_OLD.
     Conceptually, it is equivalent to executing the following commands
     in the root of the workspace:

          $ mtn rename . NEW_ROOT/PUT_OLD
          $ mtn rename NEW_ROOT .

     Except, of course, that these `rename' commands are illegal,
     because after the first command the tree has no root at all, and
     there is a directory loop.  This illegality is the only reason for
     `pivot_root''s existence; internally, the result is treated
     exactly like two renames, including with respect to merges and
     updates.

     The use of `--bookkeep-only' with this command is not recommended.
     It causes the changes to be made in monotone's records, but not in
     the filesystem itself.

     When running `pivot_root', it is sometimes possible for *note
     Workspace Collisions:: to occur.

`mtn pluck [--[no-]move-conflicting-paths] --revision=TO'
`mtn pluck [--[no-]move-conflicting-paths] --revision=FROM --revision=TO'
     See the online help for more options.

     This command takes changes made at any point in history, and
     attempts to edit your current workspace to include those changes.
     The end result is identical to running `mtn diff `-r' FROM `-r' TO
     | patch `-p0'', except that this command uses monotone's merger,
     and thus intelligently handles renames, conflicts, and so on.

     If only one revision is given, applies the changes made in TO as
     compared with TO's parent.  If two revisions are given, applies
     the changes made to get from FROM to TO.

     Note that this is not a true cherrypick operation.  A true
     cherrypick, as that word is used in version control theory,
     involves applying some changes out of context, and then recording
     the identity between the original changes and the newly applied
     changes for the use of later merges.  This command does the first
     part, not the second.  As far as monotone is concerned, the
     changes made by `mtn pluck' are exactly like those made in an
     editor; the command is simply a convenient way to make certain
     edits quickly.  In practice, this is rarely a problem.  `mtn
     pluck' should almost always be used between branches that will
     never be merged -- for instance, backporting fixes from a
     development branch to a stable branch.

     When you use `pluck' you are going behind monotone's back, and
     reducing its ability to help you keep track of what has happened in
     your history.  Never use `pluck' where a true merging command like
     `merge', `propagate', or `explicit_merge' will do.  If you find
     yourself using `pluck' often, you should consider carefully
     whether there is any way to change your workflow to reduce your
     need for `pluck'ing.

     *note Merge Conflicts:: and *note Workspace Collisions:: can occur.

`mtn rename [--bookkeep-only] SRC DST'
`mtn rename [--bookkeep-only] SRC ... DST/'
`mtn mv'
     `mv' is an alias for `rename'.

     This command places `rename' entries for the paths specified in
     SRC and DST in *note _MTN/revision::, and (if `--bookkeep-only' is
     not specified) renames the paths on the disk. This will be part of
     the next `commit'.

     The second form renames a number of source paths (or a single
     source, if DST ends in '/') to the given destination. In this case
     DST will be created if necessary, and added to the workspace if it
     is not already versioned.

     This command also moves any attributes on SRC to DST; see *note
     File Attributes:: for more details.

`mtn revert PATHNAME...'
`mtn revert --missing PATHNAME...'
     See the online help for more options.

     This command changes your workspace, so that changes you have made
     since the last checkout or update are discarded. The command is
     restricted the set of files or directories given as arguments.  To
     revert the entire workspace, use `revert' "." in the top-level
     directory. Specifying "." in a subdirectory will restrict `revert'
     to files changed within the current subdirectory.

     If `--missing' is given it reverts any versioned files in
     PATHNAME... that have been deleted from the workspace.

`mtn undrop PATHNAME...'
     Undoes a previous `drop'; useful when you make a mistake. If the
     file was deleted from the workspace, this reverts it. If it was
     not deleted (because it was changed or `--bookkeep-only' was
     given), it just removes the pending drop.

`mtn update [--[no-]move-conflicting-paths] [--branch BRANCHNAME]'
`mtn update [--[no-]move-conflicting-paths] --revision=REVISION'
     This command changes your workspace to have the a different
     revision as the base revision.

     `update' performs 3 separate stages. If any of these stages fails,
     the update aborts, doing nothing. The first two stages select the
     target revision; they are skipped if `--revision' is given - that
     revision is the target.

     In the first stage, if `--branch' is not given, the workspace
     branch is used. If `--branch' is given, the branch becomes the new
     default branch of the workspace (even if you also specify an
     explicit `--revision' argument).

        * Examine the ancestry graph of revisions on the branch in your
          database, and (subject to trust evaluation; see *note Trust
          Evaluation Hooks::) select the set of all descendants of your
          workspace's base revision. Call this set the "candidates" of
          the update.

        * Remove any candidates which lack acceptable testresult
          certificates; see *note accept_testresult_change:: (defaults
          to all candidates). From the remaining candidates, select the
          deepest child by ancestry and call it the "target" of the
          update.

        * Merge the target of the update with the workspace, in memory,
          and if the merge is successful, write the result over top of
          the workspace.

     The effect is always to take whatever changes you have made in the
     workspace, and to "transpose" them onto a new revision, using
     monotone's 3-way merge algorithm to achieve good results.  Note
     that with the explicit `--revision' argument, it is possible to
     update "backwards" or "sideways" in history -- for example,
     reverting to an earlier revision, or if your branch has two heads,
     updating to the other.  In all cases, the end result will be
     whatever revision you specified, with your local changes (and only
     your local changes) applied.

     *note Merge Conflicts:: and *note Workspace Collisions:: can occur.



File: monotone.info,  Node: Network,  Next: Informative,  Prev: Workspace,  Up: Command Reference

4.4 Network
===========

`mtn serve [--bind=[ADDRESS][:PORT]]'
`mtn pull [--[no-]set-default] [--[no-]dry-run] [URI]'
`mtn push [--[no-]set-default] [--[no-]dry-run] [--keys-to-push=KEY] [URI]'
`mtn sync [--[no-]set-default] [--[no-]dry-run] [--keys-to-push=KEY] [URI]'
`mtn pull [--[no-]set-default] [ADDRESS] [GLOB [...] [--exclude=EXCLUDE-GLOB]]] *deprecated*'
`mtn push [--[no-]set-default] [--keys-to-push=KEY] [ADDRESS] [GLOB [...] [--exclude=EXCLUDE-GLOB]]] *deprecated*'
`mtn sync [--[no-]set-default] [--keys-to-push=KEY] [ADDRESS] [GLOB [...] [--exclude=EXCLUDE-GLOB]]] *deprecated*'
     See the online help for more options. See *note --update::.

     These commands operate the "netsync" protocol built into monotone.
     This is a custom protocol for rapidly synchronizing two monotone
     databases using a hash tree index. The protocol is "peer to peer",
     but requires one peer to listen for incoming connections (the
     server) and the other peer (the client) to connect to the server.
     When run with `--stdio', the server listens for a single connection
     then terminates. When run with `--bind', or with neither option,
     the server listens for TCP connections and serves them
     continuously, until it is shut down.

     The network ADDRESS given to `serve' as an argument to `--bind'
     should be a host name to listen on, optionally followed by a colon
     and a port number. The default port number is 4691. If no `--bind'
     option is given, the server listens on port 4691 of every network
     interface.

     If `serve' is run with `--stdio', a single netsync session is
     served over the `stdin' and `stdout' file descriptors. If
     `--no-transport-auth' is provided along with `--stdio', transport
     authentication and access control mechanisms are disabled. Only
     use `--no-transport-auth' if you are certain that the transport
     channel in use already provides sufficient authentication and
     authorization facilities.

     If `--dry-run' is given, the connection is made, but no data is
     transferred. Instead, a summary of what would be transferred is
     output; the number of revisions, certs and keys that would be sent
     and received. For sent revisions, the branch names are also output.

     The URI-OR-ADDRESS arguments given to `push', `pull', and `sync'
     can be of two possible forms.

     If the argument is an URI, the Lua hook *note
     get_netsync_connect_command:: may transform it into a connection
     command, which is later executed as the transport channel for
     netsync.  The URI itself consists of a connection scheme, an
     optional user (only used for `ssh'-related transports), a host
     with an optional port (which both might be optional as well, f.e.
     for the `file' scheme), a path and a query part, which denotes one
     or more branches and optionally also exclude patterns for the
     exchange:

          <scheme>://[[<user>@]<host>[:<port>]][/<path>][?<pattern>[;-<exclude-pattern>[...]]]

     Valid examples of URIs monotone accepts are:

          mtn://my.server:4690?my.branch
          mtn://my.server/project?my.other.branch*;-my.other.branch.test
          file:///path/to/database.mtn?my.branch
          ssh://joe@my.server/~/db.mtn?joes.branch

     `file:' and `ssh:' are not supported on Windows native, but they
     are supported on Windows Cygwin.

     If the server has a multi-host setup, the path component of the URI
     might be used to distinguish between different databases (please
     ask the provider of the server for details).

     For backward compatibility, if the argument is a simple hostname
     (with no scheme, but with optional port number), monotone will
     default to the `mtn:' URI scheme, i.e. use a TCP socket to the
     specified host and port.  The GLOB parameters then indicate a set
     of branches to exchange.  Multiple GLOB and `--exclude' options
     can be specified.  *Important notice:* This call syntax is
     deprecated and subject to removal in future versions of monotone!

     For both syntaxes, every branch which matches a GLOB or branch
     pattern exactly, and does not match an EXCLUDE-GLOB or exclude
     pattern, will be indexed and made available for synchronization.

     For example, perhaps Bob and Alice wish to synchronize their
     `net.venge.monotone.win32' and `net.venge.monotone.i18n' branches.
     Supposing Alice's computer has hostname `alice.someisp.com', then
     Alice might run:

          $ mtn --bind=alice.someisp.com serve

     And Bob might run

          $ mtn sync "mtn://alice.someisp.com?net.venge.monotone*"

     When the operation completes, all branches matching
     `net.venge.monotone*' will be synchronized between Alice and Bob's
     databases.

     The `pull', `push', and `sync' commands only require you pass URI
     the first time you use one of them; monotone will store this in
     the database and in the future default to the same URI.  For
     instance, if Bob wants to `sync' with Alice again, he can simply
     run:

          $ mtn sync

     Of course, he can still `sync' with other people and other
     branches by passing an URI, address or address plus globs on the
     command line; this will not affect his default affinity for Alice.
     If you ever do want to change your defaults, simply pass the
     `--set-default' option when connecting to the server and branch
     pattern that you want to make the new default.

     The `serve' command doesn't care about workspaces, so even if you
     stand in one, you will have to give it the database to serve, the
     server key to use and the key directory explicitly.

     In the server, different permissions can be applied to each branch;
     see *note get_netsync_read_permitted:: and *note
     get_netsync_write_permitted::.

     If `--pid-file' is specified, `serve' will create the specified
     file and record the process identifier of the server in the file.
     This file can then be read to identify specific monotone server
     processes.

     The syntax for patterns is very simple.  `*' matches 0 or more
     arbitrary characters.  `?' matches exactly 1 arbitrary character
     (you need to escape that with `%3F' in a URI). `{,}' matches
     alternatives; `{foo,bar,baz}' matches "foo", or "bar", or "baz".
     These can be combined arbitrarily.  A backslash (`\') escapes
     these special characters, to match exactly that character; this
     might be useful in case someone, for some odd reason, decides to
     put a "*" into their branch name.

`mtn clone URI [--branch=BRANCHNAME] [--revision=REV] [DIRECTORY]'
`mtn clone ADDRESS[:PORT] BRANCHNAME [DIRECTORY] *deprecated*'
     `clone' is a helper command that performs the roles of a number of
     other commands all at once.  First, it constructs a new database.
     If no database is given, the configured default database is
     created or re-used (see *note get_default_database_alias:: for more
     details; `~/.monotone/default.mtn' by default). Then it populates
     this database by `pull'ing any data which match the branch pattern
     in the URI argument from the remote database.

     The branch pattern must specify a single branch; `clone' uses that
     to determine which branch to checkout.

     Finally, `clone' copies the files out of the newly created
     database into a local directory, just as `checkout' would.  If no
     DIRECTORY is given, the BRANCHNAME is used as directory. If
     `--revision' is given, that revision must be on the specified
     branch, and is checked out; otherwise the head of the branch is
     checked out.

     *Important notice:* The ADDRESS[:PORT] BRANCHNAME call syntax is
     deprecated and subject to removal in future versions of monotone!



File: monotone.info,  Node: Informative,  Next: Review,  Prev: Network,  Up: Command Reference

4.5 Informative
===============

`mtn annotate FILE'
`mtn annotate [--revision=ID] [--revs-only] FILE'
     Dumps an annotated copy of the file to stdout. The output is in the
     form:

          <short revision id>.. by <author> <date>: <line>

     <revision id> is the revision in which that line of the file was
     last edited; <author> is the author cert on that revision, <date>
     is the date cert on that revision.

     Only the first 8 characters of the revision id are displayed, the
     author cert value is truncated at the first `@' or space character
     and the date field is truncated to remove the time of day.

     If `--revs-only' is specified, the output format is:
           <revision id>: <line>

`mtn bisect bad [--revision=ID ...] [--[no-]move-conflicting-paths]'
     Mark the specified revisions as "bad" for the current bisection
     operation (see *note Bisecting::). If no bisection operation is in
     progress a new bisection is initialized. If a bisection operation
     is in progress the next update target is selected and the
     workspace is updated to the selected revision.

     If the update is blocked by conflicting unversioned paths existing
     in the workspace this command may be re-issued with the
     `--move-conflicting-paths' option. Alternatively, the `bisect
     update' command can be used with this option to update the
     workspace and move the conflicting paths out of the way.

`mtn bisect good [--revision=ID ...] [--[no-]move-conflicting-paths]'
     Mark the specified revisions as "good" for the current bisection
     operation (see *note Bisecting::). If no bisection operation is in
     progress a new bisection is initialized. If a bisection operation
     is in progress the next update target is selected and the
     workspace is updated to the selected revision.

     If the update is blocked by conflicting unversioned paths existing
     in the workspace this command may be re-issued with the
     `--move-conflicting-paths' option. Alternatively, the `bisect
     update' command can be used with this option to update the
     workspace and move the conflicting paths out of the way.

`mtn bisect reset'
     Reset the current bisection operation by updating the workspace
     back to the revision from which the bisection was started and
     clearing the current bisection information.

`mtn bisect skip [--revision=ID ...] [--[no-]move-conflicting-paths]'
     Mark the specified revisions as "skipped" for the current bisection
     operation (see *note Bisecting::). If no bisection operation is in
     progress a new bisection is initialized. If a bisection operation
     is in progress the next update target is selected and the
     workspace is updated to the selected revision.

     If the update is blocked by conflicting unversioned paths existing
     in the workspace this command may be re-issued with the
     `--move-conflicting-paths' option. Alternatively, the `bisect
     update' command can be used with this option to update the
     workspace and move the conflicting paths out of the way.

`mtn bisect status'
     Report the status of the current bisection operation including the
     number of revisions that remain to be tested, the number of
     revisions that have been tested and the next revision that will
     selected for testing.

`mtn bisect update [--[no-]move-conflicting-paths]'
     Update the workspace to the next revision selected by the previous
     bisect operation (see *note Bisecting::). This command can be
     useful when the previous bisect operation fails to update the
     workspace because of conflicting unversioned paths existing in the
     workspace.

`mtn cat [--revision=ID] PATH'
     Write the contents of a specific file PATH in revision ID (default
     to workspace base revision) to standard output.

`mtn complete file PARTIAL-ID'
`mtn complete key PARTIAL-ID'
`mtn complete revision PARTIAL-ID'
     These commands print out all known completions of a partial SHA1
     value, listing completions which are `file', `manifest' or
     `revision' IDs depending on which variant is used. For example,
     suppose you enter this command and get this result:

          $ mtn complete revision fa36
          fa36deead87811b0e15208da2853c39d2f6ebe90
          fa36b76dd0139177b28b379fe1d56b22342e5306
          fa36965ec190bee14c5afcac235f1b8e2239bb2a

     Then monotone is telling you that there are 3 revisions it knows
     about, in its database, which begin with the 4 hex digits `fa36'.
     This command is intended to be used by programmable completion
     systems, such as those in `bash' and `zsh'.

`mtn diff [--unified] [--[no-]show-encloser]'
`mtn diff --context [--[no-]show-encloser]'
`mtn diff --external [--diff-args=ARGSTRING]'
`mtn diff PATHNAME...'
`mtn diff [--reverse] --revision=ID'
`mtn diff --revision=ID PATHNAME...'
`mtn diff --revision=ID1 --revision=ID2'
`mtn diff --revision=ID1 --revision=ID2 PATHNAME...'
`mtn di'
     `di' is an alias for `diff'. See online help for more options.

     These commands print out textual difference listings between
     various manifest versions. With no `--revision' options, `diff'
     will print the difference from the base revision to the current
     revision in the workspace.

     With one `--revision' option, `diff' will print the difference
     from the revision ID to the current revision in the workspace. If
     `--reverse' is given, the order of the diff is reversed.

     With two `--revision' options `diff' will print the difference
     from revision ID1 to ID2, ignoring any workspace.

     In all cases, monotone will print a textual summary - identical to
     the summary presented by `mtn status' - of the logical differences
     between revisions in lines proceeding the diff. These lines begin
     with a single hash mark `#', and should be ignored by a program
     processing the diff, such as `patch'.

     Specifying pathnames to the `diff' command restricts the set of
     changes that are visible and results in only a partial diff between
     two revisions. Changes to files not included in the specified set
     of pathnames will be ignored.

     From within a subdirectory of the workspace the `diff' command
     will, by default, include _all changes_ in the workspace.
     Specifying only the pathname "." will restrict `diff' to files
     changed within the current subdirectory of the workspace.

     The output format of `diff' is controlled by the options
     `--unified', `--context', `--no-show-encloser', and `--external'.
     By default, monotone uses its built-in diff algorithm to produce a
     listing in "unified diff" format (analogous to running the program
     `diff `-u''); you can also explicitly request this with
     `--unified'.  The built-in diff algorithm can also produce
     "context diff" format (analogous to `diff `-c''), which you
     request by specifying `--context'.  The short options that `diff'
     accepts for these modes, `-u' and `-c', also work.

     In either of these modes, monotone prints the name of the top-level
     code construct that encloses each "hunk" of changes, unless
     suppressed with the `--no-show-encloser'.  The options that `diff'
     accepts for this mode, `-p' and `--show-c-function', also work.
     Monotone finds the enclosing construct by scanning backward from
     the first changed line in each hunk for a line that matches a
     regular expression.  The default regular expression is correct for
     many programming languages.  You can adjust the expression used
     with the Lua hook *note get_encloser_pattern::.  For the regular
     expression syntax, see *note Regexps::.

     Sometimes, you may want more flexibility in output formats; for
     these cases, you can use `--external', which causes monotone to
     invoke an external program to generate the actual output.  By
     default, the external program is `diff', and you can use the option
     `--diff-args' to pass additional arguments controlling formatting.
     The actual invocation of `diff', default arguments passed to it,
     and so on, are controlled by the hook *note external_diff::.

`mtn help [--[no-]hidden] COMMAND...'
     Displays help about commands and options.

`mtn list branches [PATTERN] [--exclude=PATTERN]'
`mtn ls branches'
     `ls branches' is an alias for `list branches'.

     This command lists all known branches in your database. If PATTERN
     is provided, it is used as a glob to select the branches listed,
     otherwise all branches are listed.  If `-exclude' options are
     provided they are used as globs to exclude specified branches. In
     addition, branches for which the Lua hook *note ignore_branch::
     returns true are excluded.

     Normally, branches that have been suspended are not listed; the
     global option `--ignore-suspend-certs' causes suspended branches to
     be listed; see `*note mtn suspend::'.

`mtn list certs ID'
`mtn ls certs'
     `ls certs' is an alias for `list certs'.

     This command will print out a list of certificates associated with
     a particular revision ID. Each line of the print out will indicate:
        * The key used to sign the certificate

        * Whether the signature on the certificate is `ok' or `bad'

        * The name of the certificate

        * The value of the certificate

     For example, this command lists the certificates associated with a
     particular version of monotone itself, in the monotone development
     branch:

          $ mtn list certs 4a96
          mtn: expanding partial id '4a96'
          mtn: expanded to '4a96a230293456baa9c6e7167cafb3c5b52a8e7f'
          -----------------------------------------------------------------
          Key   : graydon@pobox.com (10b5b36b4a...)
          Sig   : ok
          Name  : author
          Value : graydon@dub.venge.net
          -----------------------------------------------------------------
          Key   : graydon@pobox.com (10b5b36b4a...)
          Sig   : ok
          Name  : branch
          Value : monotone
          -----------------------------------------------------------------
          Key   : graydon@pobox.com (10b5b36b4a...)
          Sig   : ok
          Name  : date
          Value : 2003-10-17T03:20:27
          -----------------------------------------------------------------
          Key   : graydon@pobox.com (10b5b36b4a...)
          Sig   : ok
          Name  : changelog
          Value : 2003-10-16  graydon hoare  <graydon@pobox.com>
                :
                :         * sanity.hh: Add a const version of idx().
                :         * diff_patch.cc: Change to using idx() everywhere.
                :         * cert.cc (find_common_ancestor): Rewrite to recursive
                :         form, stepping over historic merges.
                :         * tests/t_cross.at: New test for merging merges.
                :         * testsuite.at: Call t_cross.at.
                :

`mtn list changed [PATHNAME...]'
`mtn ls changed'
     `ls changed' is an alias for `list changed'.  See online help for
     more options.

     This command lists all files in your workspace that have changed
     compared to the base revision, including files that are dropped,
     added or renamed.

     Specifying pathnames to the `list changed' command restricts the
     set of paths that are checked for changes. Files not included in
     the specified set of pathnames will not be listed.

     From within a subdirectory of the workspace the `list changed'
     command will, by default, search the entire workspace.  Specifying
     only the pathname "." will restrict the search for known files to
     the current subdirectory of the workspace.

`mtn list databases'
`mtn list dbs'
`mtn ls databases'
`mtn ls dbs'
     Show all *note Managed Databases:: and the workspaces registered in
     them. The commands `*note mtn register_workspace::' and `*note mtn
     unregister_workspace::' can be used to explicitely register and
     unregister workspaces shown within this list.

`mtn list duplicates [--revision=ID]'
`mtn ls duplicates'
     `ls duplicates' is an alias for `list duplicates'.

     This command lists duplicate files in a given revision (defaults to
     the workspace base revision). Ignored and unknown files are
     excluded from the listing.

     Two or more files are considered duplicates if the SHA1 hashes of
     their contents are equal.

`mtn list ignored [PATHNAME...]'
`mtn ls ignored'
     `ls ignored' is an alias for `list ignored'.

     This command lists all files in your workspace that monotone is
     intentionally ignoring, due to the results of the *note
     ignore_file:: hook.

     Specifying pathnames to the `list ignored' command restricts the
     set of paths that are searched for ignored files. Ignored files not
     included in the specified set of pathnames will not be listed.

     From within a subdirectory of the workspace the `list ignored'
     command will, by default, search the entire workspace.  Specifying
     only the pathname "." will restrict the search for ignored files
     to the current subdirectory of the workspace.

`mtn list keys [PATTERN]'
`mtn ls keys'
     `ls keys' is an alias for `list keys'.

     These commands list RSA keys held in your keystore and current
     database.  They do not print out any cryptographic information;
     they simply list the names of public and private keys you have on
     hand.

     If PATTERN is provided, it is used as a glob to limit the keys
     listed. Otherwise all keys in your database are listed.

`mtn list known [PATHNAME...]'
`mtn ls known'
     `ls known' is an alias for `list known'.

     This command lists all files which would become part of the
     manifest of the next revision if you committed your workspace at
     this point.

     Specifying pathnames to the `list known' command restricts the set
     of paths that are searched for manifest files. Files not included
     in the specified set of pathnames will not be listed.

     From within a subdirectory of the workspace the `list known'
     command will, by default, search the entire workspace.  Specifying
     only the pathname "." will restrict the search for known files to
     the current subdirectory of the workspace.

`mtn list missing [PATHNAME...]'
`mtn ls missing'
     `ls missing' is an alias for `list missing'.

     This command lists all files in your workspace's base manifest,
     which are not present in the workspace.

     Specifying pathnames to the `list missing' command restricts the
     set of paths that are searched for missing files. Missing files not
     included in the specified set of pathnames will not be listed.

     From within a subdirectory of the workspace the `list missing'
     command will, by default, search the entire workspace.  Specifying
     only the pathname "." will restrict the search for missing files
     to the current subdirectory of the workspace.

`mtn list tags [PATTERN] [--exclude=PATTERN]'
`mtn ls tags'
     `ls tags' is an alias for `list tags'.

     This command lists all known tags in your database that match the
     given PATTERN (default all tags).  If `--exclude' options are
     provided they are used as globs to exclude specified tags.

`mtn list unknown [PATHNAME...]'
`mtn ls unknown'
     `ls unknown' is an alias for `list unknown'.

     This command lists all files in your workspace that monotone knows
     nothing about.

     Specifying pathnames to the `list unknown' command restricts the
     set of paths that are searched for unknown files. Unknown files not
     included in the specified set of pathnames will not be listed.

     From within a subdirectory of the workspace the `list unknown'
     command will, by default, search the entire workspace.  Specifying
     only the pathname "." will restrict the search for unknown files
     to the current subdirectory of the workspace.

`mtn list vars [DOMAIN]'
`mtn ls vars'
     `ls vars' is an alias for `list vars'.

     This command lists all vars in your database, or all vars within a
     given DOMAIN.  See *note Vars:: for more information.

`mtn list workspaces'
`mtn ls workspaces'
     `ls workspaces' is an alias for `list workspaces'.

     This command shows all registered workspaces for a database, be it
     managed or unmanaged.  If no database is given explicitely,
     defaults to the workspace' database in which the command is
     executed.  The commands `*note mtn register_workspace::' and
     `*note mtn unregister_workspace::' can be used to explicitely
     register and unregister workspaces shown within this list.  See
     *note Managed Databases:: for more information.

`mtn log'
`mtn log [--last=N] [--next=N] [--from=ID [...]] [--clear-from] [--to=ID [...]] [--clear-to] [--revision=ID [...]] [--[no-]brief] [--[no-]merges] [--[no-]files] [--[no-]graph] [--[no-]diffs] [PATHNAME...]'
     See the online help for more options.

     This command prints out a log, in forward ancestry order by default
     but optionally in reverse ancestry order, of small history
     summaries.  Each summary contains author, date, branch, changelog
     and comment information associated with a revision.

     If `--brief' is given, the output consists of two lines per
     revision with the revision ID, the author, the date and the
     branches (separated with commas). If the `--no-graph' option is
     also given the output contains only one line per revision.

     If `--last='N is given, at most N log entries will be given and
     log will trace through history in reverse-ancestry order, from
     newer revisions to older revisions.

     If `--next='N is given, at most N log entries will be given and
     log will trace through history in forward-ancestry order, from
     older revisions to newer revisions. This is useful to review
     changes that will be applied to the workspace when `update' is run.

     If `--from='ID is given, log starts tracing through history from
     the specified revisions, otherwise it starts from the base
     revision of your workspace. Log will stop when it reaches the end
     of the revision history or revisions specified by the `--to'
     option.

     `--clear-from' erases the effect of all previous `--from' options.
     `--clear-to' erases the effect of all previous `--to' options.

     When tracing through history in reverse-ancestry order and
     `--to='ID is given, log will stop when it reaches the specified
     revisions or any of their ancestors or the end of the revision
     history. When tracing through history in forward-ancestry order
     log will stop when it reaches the specified revisions or any of
     their descendants or the end of the revision history.

     If `--revision='ID is given, log will print only the specified
     revisions.

     If both `--from' and `--revision' are given only revisions
     included by both options will be logged. Revisions specified by
     `--revision' that are beyond the starting points specified by
     `--from' will be excluded.

     Additionally, each of the `--from', `--to' and `--revision'
     options accept selectors, see *note Selectors::. These can be used
     in various ways to log interesting revisions.  For example: $ mtn log --revision b:
     $ mtn log --revision today
     $ mtn log --revision bob
      will log all revisions from the current branch, all revisions
     dated today and all revisions with bob as the author, respectively.

     By default, the log entries for merge nodes are shown.  If
     `--no-merges' is given, the log entries for these nodes will be
     excluded.

     If `--no-files' is given, the log output excludes the list of
     files changed in each revision.

     If `--no-graph' is given, the log output excludes the ASCII
     revision graph prefix on log output lines.

     Specifying `--diffs' causes the log output to include a unified
     diff of the changes in each revision.

     If one or more files are given, the command will only log the
     revisions where those files are changed.

`mtn manpage [--formatted/--plain] [--[no-]hidden]'
     The manpage command generates a complete (and if monotone is
     available in your language, also localized) manual page for all
     available commands, including all user-defined Lua commands.

     The default for `--formatted/--plain' depends on whether `mtn
     manpage' is run from a terminal, or from a shell script. From a
     terminal, the default is `--formatted'; from a script, it is
     `--plain'.

     If `--formatted', the output is formatted and displayed using the
     command given by the Lua hook `*note
     get_man_page_formatter_command::' (defaults to `nroff | less').

     If `--plain', the output is nroff markup.

     The option `--hidden' additionally enables the output of hidden
     commands and options, which is deactivated by default.

`mtn show_conflicts REV REV'
     This command shows what conflicts would need to be resolved in
     order to merge the given revisions; see *note Merge Conflicts::.

     Note that this does not show conflicts due to update commands,
     since in that case one revision is the workspace.

`mtn status [PATHNAME...]'
     This command prints a description of the "status" of your
     workspace.  In particular, it prints:
        * The branch currently selected in `_MTN/options' for the
          workspace.

        * The revision id of the "parent" revision of the workspace, on
          which your in-progress changes are based.

        * A list of logical changes between the base and current
          manifest versions, such as adds, drops, renames, and patches.

     Specifying optional PATHNAME... arguments to the `status' command
     restricts the set of changes that are visible and results in only
     a partial status of the workspace. Changes to files not included
     in the specified set of pathnames will be ignored.

     From within a subdirectory of the workspace the `status' command
     will, by default, include _all changes_ in the workspace.
     Specifying only the pathname "." will restrict `status' to files
     changed within the current subdirectory of the workspace.

`mtn version [--full | --concise]'
     Shows the program version.

     The concise version is one line, for example:
          monotone 1.0dev (base revision: c91edf22b20f5a8b750a8a02af763412d6b936e8)

     The full version gives more information, including a changelist of
     the monotone source tree from the base revision at the time the
     executable was compiled.



File: monotone.info,  Node: Review,  Next: Variables,  Prev: Informative,  Up: Command Reference

4.6 Review
==========

`mtn approve REV [--branch=BRANCHNAME] [--[no-]update]'
     This command puts REV on the branch BRANCHNAME (defaults to the
     workspace branch).

     This command is a synonym for `mtn cert REV branch BRANCHNAME'.

     See *note --update::.

`mtn comment REV [COMMENT]'
     This adds a new comment to a committed revision.  If COMMENT is
     not provided, it is obtained from the Lua hook `*note
     edit_comment::'; the hook is passed an empty string.

     This command is a synonym for `mtn cert REV comment COMMENT'.

`mtn disapprove [--[no-]update] [PARENT] CHILD'
     See online help for more options; see *note Common Options::. See
     *note --update::.

     This command records a disapproval of the changes between PARENT's
     ancestor and CHILD.  If PARENT is omitted, only CHILD is
     disapproved.  The command does the disapproval by committing the
     inverse changes as a new revision descending from CHILD.

     Conceptually, `disapprove''s contract is that disapprove(A) gives a
     revision B such that whenever B is merged with a descendant D of A
     the merge will result in what D "would have looked like" if A had
     never happened.

     Note that as a consequence of this contract the `disapprove'
     command only works if all changesets from PARENT to CHILD have
     exactly one ancestor (that is, none are the result of a merge),
     since it hasn't been worked out how to generate such a descendant
     in the multi-ancestor case.

`mtn suspend [--[no-]update] [--branch BRANCHNAME] REV'
     See *note --update::.

     This makes REV invisible as a head of branch BRANCHNAME (defaults
     to the current workspace branch).  Any operation that looks for
     heads will not count REV; this includes `*note mtn list
     branches::' as well as `*note mtn merge::' etc.

     If REV is not a head, `suspend' has no effect.

     `suspend' is not inherited; if a new revision is committed as the
     child of a `suspend'ed revision, the new revision will be visible
     as a head.

     This command is a synonym for `mtn cert REV suspend BRANCHNAME'.

`mtn tag REV TAGNAME'
     This command associates the symbolic name TAGNAME with the
     revision REV, so that symbolic name can later be used in *note
     Selectors:: for specifying revisions.

     This command is a synonym for `mtn cert REV tag TAGNAME'.

`mtn testresult REV {pass | fail | true | false | yes | no | 1 | 0}'
     This command adds a `testresult' certificate to REV, with a value
     of 0 or 1. `pass', `true', `yes' give a value of 1; `fail',
     `false', `no' give a value of 0. See *note Quality Assurance::.



File: monotone.info,  Node: Variables,  Next: Key and Cert,  Prev: Review,  Up: Command Reference

4.7 Variables
=============

`mtn cleanup_workspace_list'
     Removes all invalid workspaces from the list of registered
     workspaces of the current database.  A workspace is considered
     invalid if its path does either not contain an `_MTN' directory
     anymore or if the configured database for the workspace is a
     different from the current database.

`mtn register_workspace [WORKSPACE_PATH]'
     Registers the given workspace (default the current workspace) in
     the current database, so that it will show up in the output of
     `*note mtn list databases::' (the database has to be in a managed
     location for `list databases' to work; see *note Managed
     Databases::).

`mtn set DOMAIN NAME VALUE'
     Associates VALUE to NAME in domain DOMAIN.  See *note Vars:: for
     more information.

`mtn unregister_workspace [WORKSPACE_PATH]'
     Unregisters the given workspace (default the current workspace)
     from the current database, so that it will no longer show up in
     the output of `*note mtn list databases::'.

`mtn unset DOMAIN NAME'
     Deletes any value associated with NAME in DOMAIN.  See *note
     Vars:: for more information.



File: monotone.info,  Node: Key and Cert,  Next: Packet I/O,  Prev: Variables,  Up: Command Reference

4.8 Key and Cert
================

`mtn cert SELECTOR CERTNAME [CERTVAL]'
     Create a new certificate with name CERTNAME, for all revisions
     matching SELECTOR.

     If CERTVAL is provided, it is the value of the certificate.
     Otherwise the certificate value is read from `stdin'.

`mtn dropkey KEYID'
     Drop the public and/or private key. This command should be used
     with caution as changes are irreversible without a backup of the
     key(s) that were dropped.

`mtn genkey KEYID'
     This command generates an RSA public/private key pair, using a
     system random number generator, and stores it in your keystore
     under the key name KEYID.KEYHASH.  The key's hash is printed out
     after the key has been created.

     The private half of the key is stored in an encrypted form, so that
     anyone who can read your keystore cannot extract your private key
     and use it.  You must provide a passphrase for your key when it is
     generated, which is used to determine the encryption key. In the
     future you will need to enter this passphrase again each time you
     sign a certificate, which happens every time you `commit' to your
     database. You can tell monotone to automatically use a certain
     passphrase for a given key using the
     `get_passphrase(KEY_IDENTITY)' (see *note get_passphrase::), but
     this significantly increases the risk of a key compromise on your
     local computer. Be careful using this hook.

     Another way to avoid entering the private key passphrase each time
     it is needed is to export it to ssh-agent; see *note mtn
     ssh_agent_export::, *note mtn ssh_agent_add::.

     The public key is stored in the database; the public and private
     keys are stored in the keystore. This allows copying the database
     without copying the private key.

     The location of the keystore is specified by `--keydir'; it
     defaults to the value stored in `_MTN/options' for commands
     executed in a workspace, or to the system default
     (`$HOME/.monotone/keys' on Unix and Cygwin,
     `%APPDATA%/monotone/keys' on native Win32).

`mtn passphrase KEYID'
     This command lets you change the passphrase of the private half of
     the key ID.

`mtn ssh_agent_add'
     This command will add your monotone keys to your current ssh-agent
     session.  You will be asked for the passphrase for each of your
     monotone private keys and they will be added to the ssh-agent.
     Once this is done you should be able to type _ssh-add -l_ and see
     your monotone key listed. When you subsequently use these keys
     through monotone it will use ssh-agent for signing without asking
     your for your passphrase.

     On Windows native, monotone only supports the PuTTY ssh-agent
     implementation. On Windows Cygwin and Unix, any standard ssh-agent
     implementation can be used.

     This command is mainly for use in a session script as monotone
     will automatically add your keys to ssh-agent on first use if it
     is available. For example the following two examples are
     equivalent:

          $ mtn ssh_agent_add
          enter passphrase for key ID [user@example.com]:
          $ mtn ci -m"Changed foo to bar"
          $ mtn push -k user@example.com

          $ mtn ci -m"Changed foo to bar"
          enter passphrase for key ID [user@example.com]:
          $ mtn push -k user@example.com

     In the second example, monotone automatically added the key to
     ssh-agent, making entering the passphrase not needed during the
     push.

`mtn ssh_agent_export [FILENAME]'
     This command will export your private key in a format that
     ssh-agent can read (PKCS8, PEM), to FILENAME (defaults to standard
     output). You will be asked for your current key's monotone password
     and a new password to encrypt the key with (the ssh passphrase).
     The key will be printed to stdout. Once you have put this key in a
     file simply add it to ssh-agent and you will only have to enter
     your key password once as ssh-agent will cache the key for you.

          $ mtn ssh_agent_export ~/.ssh/id_monotone
          enter passphrase for key ID [user@example.com] (1234abcd...):
          enter new passphrase for key ID [user@example.com] (1234abcd...):
          confirm passphrase for key ID [user@example.com] (1234abcd...):
          $ chmod 600 ~/.ssh/id_monotone
          $ ssh-agent /bin/bash
          $ ssh-add ~/.ssh/id_monotone
          Enter passphrase for /home/user/.ssh/id_monotone:
          Identity added: /home/user/.ssh/id_monotone (/home/user/.ssh/id_monotone)
          $ mtn ci -m"Changed foo to bar"
          $ mtn push -k user@example.com

     You can also use the `--ssh-sign' option to control whether
     ssh-agent will be used for signing. If set to _yes_, ssh-agent
     will be used to sign. If your key has not been added to ssh-agent
     monotone will fall back to its internal signing code and ask you
     for your password. If set to _only_, monotone will sign only with
     ssh-agent. If set to _no_, monotone will always use its internal
     signing code even if ssh-agent is running and has your monotone
     key loaded. If set to _check_, monotone will sign with both
     ssh-agent (if your key is loaded into it) and monotone's internal
     signing code, then compare the results. _check_ will be removed at
     some future time as it is meant only for testing and will not work
     with all signing algorithms.

`mtn trusted ID CERTNAME CERTVAL SIGNERS'
     This command lets you test your revision trust hook *note
     get_revision_cert_trust::.  You pass it a revision ID, a
     certificate name, a certificate value, and one or more key IDs or
     key names, and it will tell you whether, under your current
     settings, Monotone would trust a cert on that revision with that
     value signed by those keys.

     The specified keys must exist either in your keystore or in the
     database.



File: monotone.info,  Node: Packet I/O,  Next: Database,  Prev: Key and Cert,  Up: Command Reference

4.9 Packet I/O
==============

Monotone can produce and consume data in a convenient, portable form
called "packets". A packet is a sequence of ASCII text, wrapped at
70-columns and easily sent through email or other transports. If you
wish to manually transmit a piece of information - for example a public
key - from one monotone database to another, it is often convenient to
read and write packets.

   _Note:_ earlier versions of monotone queued and replayed packet
streams for their networking system. This older networking system has
been removed, as the netsync protocol has several properties which make
it a superior communication system. However, the packet I/O facility
will remain in monotone as a utility for moving individual data items
around manually.

`mtn privkey KEYID'
`mtn pubkey KEYID'
     These commands print out an `keypair' or `pubkey' packet for the
     RSA key KEYID. These can be used to transport public or private
     keys safely between monotone databases.

`mtn read [FILE...]'
     This command reads packets from files or `stdin' and stores them
     in your database.



File: monotone.info,  Node: Database,  Next: Automation,  Prev: Packet I/O,  Up: Command Reference

4.10 Database
=============

All of these commands require that the database is specified, either
via `--db' or the current workspace.

`mtn db changesetify [--db=DBFILE]'
     Converts the database to the changeset format.

     This is only needed when upgrading very old monotone databases,
     created with monotone versions less than 0.15.

`mtn db check [--db=DBFILE]'
     Monotone always works hard to verify the data it creates and
     accesses.  For instance, if you have hard drive problems that
     corrupt data in monotone's database, and you attempt to retrieve
     this data, then monotone will notice the problem and stop, instead
     of silently giving you garbage data.

     However, it's also nice to notice such problems early, and in
     rarely used parts of history, while you still have backups.
     That's what this command is for.  It systematically checks the
     database DBFILE to ensure that it is complete and consistent. The
     following problems are detected:

        * missing files that are referenced by their SHA1 hash from
          some manifest but do not exist in the database.  This is a
          serious problem; it means that your history is not fully
          reconstructible.  You can fix it by finding the file with the
          given hash, and loading it into your database with `fload'.

        * unreferenced files that exist in the database but are not
          referenced by their SHA1 hash from any existing manifest.  In
          itself, this only indicates some wasted space, and is not a
          problem; it's possible it could arise under normal use (for
          instance, in some strange corner cases following an
          incomplete netsync).  It could also arise, though, as a
          symptom of some other more serious problem.

        * missing manifests that are referenced by their SHA1 hash from
          some revision but do not exist in the database.  This is a
          serious problem; it means that your history is not fully
          reconstructible.  You can fix it by finding a database
          containing the manifest, and using `mdata' on that database
          to create a manifest data packet, which can be loaded into
          your database with `read'.

        * unreferenced rosters that exist in the database but are not
          referenced by their SHA1 hash from any existing revision.  In
          itself, this only indicates some wasted space, and is not a
          problem; it's possible it could arise under normal use (for
          instance, if you have run `local kill_revision', or in some
          strange-but-harmless corner cases following an incomplete
          netsync).  It could also arise, though, as a symptom of some
          other more serious problem.

        * incomplete manifests that exist in the database but contain
          references to files that do not exist in the database.  For
          diagnosis and solution, see "missing files" above.

        * missing revisions that are referenced by their SHA1 hash from
          some other revision or revision cert but do not exist in the
          database.  This may be a serious problem; it may indicate
          that your history is not fully reconstructible (if the
          reference is from another revision) or that someone is
          creating bogus certs (if the reference is from a cert).  You
          can fix it by finding a database containing the revision, and
          using `rdata' on that database to create a revision data
          packet, which can be loaded into your database with `read'.

        * incomplete revisions that exist in the database but contain
          references to missing manifests, incomplete manifests or
          missing revisions.  This always occurs with some more
          detailed error; see above.

        * revisions with mismatched parents that disagree with the
          cached revision ancestry on their parent revisions.  This may
          cause problems in using the database, and suggests the
          presence of a bug in monotone's caching system, but does not
          involve data loss.

        * revisions with mismatched children that disagree with the
          cached revision ancestry on their child revisions.  This may
          cause problems in using the database, and suggests the
          presence of a bug in monotone's caching system, but does not
          involve data loss.

        * revisions with bad history that exist in the database but
          fail monotone's normal sanity checks for consistent and
          correct history.  This is a serious problem; it indicates
          that your history record is somehow malformed.  This should
          not be possible, since monotone carefully checks every
          revision before storing it into the database, but if it does,
          then please request assistance on the monotone mailing list.
          Fixing this generally means you may lose some history -- for
          instance, renames may be degraded into delete/add pairs --
          but the actual contents of every revision will still be
          reproducible.

        * revisions with missing certs that exist in the database
          lacking at least one author, branch, changelog or date cert.
          All revisions are expected to have at least one of each of
          these certs.  In itself, this is not necessarily a problem,
          but it is peculiar, and some operations such as netsync may
          behave strangely.

        * revisions with mismatched certs that exist in the database
          with differing numbers of author, changelog and date certs.
          These certs are expected to appear together, as each revision
          committed should have an author, changelog and date associated
          with it.  In itself, this is not a problem, but it is
          peculiar.  All operations should behave normally.

        * missing keys that have been used to sign certs but do not
          exist in the database.  In itself, this is not a problem,
          except that monotone will ignore any certs signed by the
          missing key.  You can fix it by finding a database containing
          the key in question, and using `pubkey' on that database to
          create a public key packet, which can be loaded into your
          database with `read'.

        * certs with bad signatures that exist in the database with
          signatures that are invalid.  In itself, this is not a
          problem, except that monotone will ignore any such certs.
          You may also wish to find out who is creating certs with bad
          signatures; it may indicate some kind of security attack.

        * certs with unchecked signatures that exist in the database
          but cannot have their signatures checked because the signing
          key is missing.  In itself, this is not a problem, except
          that monotone will ignore any certs signed by the missing key.
          You can fix it by finding a database containing the key in
          question, and using `pubkey' on that database to create a
          public key packet, which can be loaded into your database
          with `read'.

        * branches not used or with incorrect head count or missing in
          the cache of branch heads. This is a serious problem; it
          suggests the presence of a bug in monotone's caching system,
          but does not involve data loss; please report this on the
          monotone mailing list. You can fix it by running `db
          regenerate_caches'.


     This command also verifies that the SHA1 hash of every file,
     manifest, and revision is correct.

`mtn db dump [--db=DBFILE]'
     This command dumps a sequence of SQL instructions representing the
     entire state of DBFILE to the standard output stream. It is a very
     low-level command, and produces the most "recoverable" dumps of
     your database possible. It is sometimes also useful when migrating
     databases between variants of the underlying SQLite database
     format.

`mtn db execute [--db=DBFILE] SQL-STATEMENT'
     This is a debugging command which executes SQL-STATEMENT against
     your database, and prints any results of the expression in a
     tabular form.  It can be used to investigate the state of your
     database, or help diagnose failures.

`mtn db fix_certs [--db=DBFILE] [--drop-bad-certs]'
     Attempt to fix bad certs.

     Older monotone versions could sometimes associate certs with the
     wrong key. This fixes such certs if you have the correct key, and
     if `--drop-bad-certs' is given, drops any certs that you don't
     have the correct key for. This should only be needed if you had
     such certs in your db when upgrading from monotone 0.44 or
     earlier, or if you loaded such certs with 'mtn read'.

`mtn db info [--db=DBFILE] [--full | --concise]'
     This command prints information about the monotone database
     DBFILE, including its schema version and various table size
     statistics. `--full' prints additional info about timestamps; the
     default is `--concise'.

`mtn db init [--db=DBFILE]'
     This command creates and initializes a new monotone database at
     DBFILE.

`mtn db load [--db=DBFILE]'
     This command applies a raw SQL statement, read from the standard
     input stream, to the database DBFILE. It is most useful when
     loading a database dumped with the `dump' command.

     Note that when reloading a dumped database, the schema of the
     dumped database is _included_ in the dump, so you should not try to
     `init' your database before a `load'.

`mtn db migrate [--db=DBFILE]'
     This command attempts to migrate the database DBFILE to the newest
     schema known by the version of monotone you are currently running.
     If the migration fails, no changes should be made to the database.

     If you have important information in your database, you should
     back up a copy of it before migrating, in case there is an
     untrapped error during migration.

`mtn db regenerate_caches'
     Regenerates the caches stored in the database.

     This is only needed to recover from a newly discovered bug in
     monotone, or if your database becomes corrupted for some other
     reason.

`mtn db rosterify'
     Converts the database to the rosters format.

     This is only needed when upgrading very old monotone databases,
     created with monotone versions less than 0.15.

`mtn db set_epoch BRANCH EPOCH'
     Sets the branch's epoch. See *note Rebuilding ancestry:: for
     discussion of epochs.

`mtn db version [--db=DBFILE]'
     This command prints out just the schema version of the monotone
     database DBFILE.

`mtn local kill_certs SELECTOR CERTNAME [CERTVAL]'
     This command deletes certs with the given name on revisions that
     match the given selector. If a value is given, it restricts itself
     to only delete certs that also have that same value. Like `*note
     mtn local kill_revision::', it is a very dangerous command; it
     permanently and irrevocably deletes historical information from
     your database. Also like `kill_revision', this only deletes the
     certs from your local database; if there are other databases that
     you sync with which have these certs they will reappear when you
     sync, unless the owners of those databases also delete those
     certificates locally.

     Early versions of monotone had `db kill_tag_locally' and `db
     kill_branch_certs_locally' commands. These can be emulated with
     `local kill_certs i: tag TAG' and `local kill_certs i: branch
     BRANCH', respectively.

`mtn local kill_revision ID'
     This command "kills", i.e., deletes, a given revision, as well as
     any certs attached to it.  It is a very dangerous command; it
     permanently and irrevocably deletes historical information from
     your database.  If you execute this command in a workspace, whose
     parent revision is the one you are about to delete, the killed
     revision is re-applied to this workspace which makes it possible
     for you to fix a problem and commit again later on easily. For
     this to work, the workspace may not have any changes and/or
     missing files.

     There are a number of other caveats with this command:
        * It can only be applied to revisions that have no descendants.
          If you want to kill a revision that has descendants, you must
          kill all of the descendants first.

        * It only removes the revision from your local database (hence
          the "local" in the command name).  If you have already pushed
          this revision out to another database, then the next time you
          pull from that database it may come back again.  There is no
          way to delete a revision from somebody else's database except
          to ask them to delete it for you.

        * It does not actually delete the revision's files or manifest
          from your database.  If you run this command, and then run
          `db check', it will note that you have an "unreferenced
          roster".  If you wish to eliminate this data for good (and
          thus free up the space), you may use netsync to `pull' from
          your current database into a new database; this creates a
          copy of your old database, without the unreferenced data.
          However, having this data in your database will not cause any
          problems, and acts as a safety net; if you later realize that
          you do, after all, need to retrieve the data in ID, then `db
          check' will let you see which manifest it was, and with some
          work you can extract ID's data.



File: monotone.info,  Node: Automation,  Next: VCS,  Prev: Database,  Up: Command Reference

4.11 Automation
===============

This section contains subcommands of the `mtn automate' command, used
for scripting monotone.  All give output on `stdout'; they may also
give useful chatter on `stderr', including warnings and error messages.

   When run under *note mtn automate stdio::, there are five output
streams available; main, error, warning, progress, and ticker. When run
under `mtn automate', the main stream goes to stdout, and the error,
warning, progress, and ticker streams all go to stderr.

   Many commands produce output in a format called basic_io; for more
information, *note Formats::.

   Revision arguments to automate commands must be hex ids, not
selectors.

`mtn automate ancestors REV...'

    *Arguments:*
          One or more revision IDs.

    *Added in:*
          0.2

    *Purpose:*
          Prints the ancestors of one or more revisions.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one ancestor of the
          given revisions.  Each line consists of a revision ID, in
          hexadecimal, followed by a newline.  The lines are printed in
          alphabetically sorted order.

          The output does not include the specified revisions, except if
          one of them is an ancestor of another.

    *Error conditions:*
          If any of the revisions do not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate ancestry_difference NEW [OLD...]'

    *Arguments:*
          A "new" revision ID NEW, followed by zero or more "old"
          revision IDs OLD....

    *Added in:*
          0.1

    *Purpose:*
          Prints all ancestors of the new revision, that are not also
          ancestors of one of the old revisions.  For purposes of this
          command, "ancestor" is an inclusive term; each revision is an
          ancestor of itself. For example, if NEW is an ancestor of any
          of OLD..., NEW will not be printed; but if NEW is not an
          ancestor of any of the "old" revisions, then it will be.
          Similarly, none of OLD... will be printed.

          The reason for the names NEW and OLD is that if NEW is a
          newer revision than OLD..., then this command tells you which
          all revisions that are newer than OLD..., and are also
          ancestors of NEW.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          A list of revision IDs, in hexadecimal, each followed by a
          newline.  Revisions are printed in topologically sorted order.

    *Error conditions:*
          If any of the revisions do not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate branches'

    *Arguments:*
          None.

    *Added in:*
          2.2

    *Purpose:*
          Prints all branch certs present in the revision graph, that
          are not excluded by the Lua hook `*note ignore_branch::'.

    *Sample output:*
          net.venge.monotone
          net.venge.monotone.win32

    *Output format:*
          Zero or more lines, each the name of a branch. The lines are
          printed in alphabetically sorted order.

    *Error conditions:*
          None.


`mtn automate cert REVISION NAME VALUE'

    *Arguments:*
          REVISION is an existing revision, NAME is the certificate name
          and VALUE its value.

    *Added in:*
          4.1

    *Purpose:*
          `automate' variant of `*note mtn cert::'.

    *Sample usage:*
          mtn automate cert 4c2c1d846fa561601254200918fba1fd71e6795d author tester@test.net

    *Output format:*
          No output.

    *Error conditions:*
          If the revision is invalid prints an error message to stderr
          and exits with status 1.


`mtn automate certs ID'

    *Arguments:*
          A revision ID ID, for which any certificates will be printed.

    *Changes:*
             * 11.0 - Keys are now listed by hash instead of name.

             * 1.0 - Added.

    *Purpose:*
          Prints all certificates associated with the given revision ID.
          Each certificate is contained in a basic IO stanza. For each
          certificate, the following values are provided: 'key'
                the hex-encoded hash of the key used to sign this certificate.
          'signature'
                a string indicating the status of the signature. Possible
                values of this string are:
                      'ok'        : the signature is correct
                      'bad'       : the signature is invalid
                      'unknown'   : signature was made with an unknown key
          'name'
                the name of this certificate
          'value'
                the value of this certificate
          'trust'
                is this certificate trusted by the defined trust metric?
                Possible values of this string are:
                      'trusted'   : this certificate is trusted
                      'untrusted' : this certificate is not trusted

    *Sample output:*
                key [5cd3b3a7ad2e8645e8887af193ee522dc59112e4]
          signature "ok"
               name "author"
              value "emile@alumni.reed.edu"
              trust "trusted"

                key [5cd3b3a7ad2e8645e8887af193ee522dc59112e4]
          signature "ok"
               name "branch"
              value "net.venge.monotone"
              trust "trusted"

                key [5cd3b3a7ad2e8645e8887af193ee522dc59112e4]
          signature "ok"
               name "changelog"
              value "propagate from branch 'net.venge.monotone.annotate' (head 76a886ef7c8ae12a4bba5fc2bd252557bf863aff)
                      to branch 'net.venge.monotone' (head 2490479a4e4e99243fead6d627d78291fde592f0)
          "
              trust "trusted"

                key [5cd3b3a7ad2e8645e8887af193ee522dc59112e4]
          signature "ok"
               name "date"
              value "2005-05-20T20:19:25"
              trust "trusted"

    *Output format:*
          All stanzas are formatted by basic_io. Stanzas are separated
          by a blank line. Values will be escaped, '\' to '\\' and '"'
          to '\"'.

    *Error conditions:*
          If a certificate is signed with an unknown public key, a
          warning message is printed to stderr. If the revision
          specified is unknown or invalid prints an error message to
          stderr and exits with status 1.


`mtn automate checkout [--[no-]move-conflicting-paths] [--revision=ID] [--branch=BRANCHNAME] DIRECTORY'

    *Arguments:*
          Options and arguments are the same as `*note mtn checkout::'.

    *Changes:*
          13.0 - initial

    *Purpose:*
          Create a new workspace containing the given revision; see
          `*note mtn checkout::'.

    *Sample output:*
          None.

    *Output format:*
          None.

    *Error conditions:*
          see `*note mtn checkout::'.


`mtn automate children REV'

    *Arguments:*
          One revision ID, REV.

    *Added in:*
          0.2

    *Purpose:*
          Prints the immediate children of a revision.  This is like a
          non-recursive version of `*note mtn automate descendents::'.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one child of the
          given revision.  Each line consists of a revision ID, in
          hexadecimal, followed by a newline.  The lines are printed in
          alphabetically sorted order.

    *Error conditions:*
          If the given revision REV does not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate common_ancestors REV...'

    *Arguments:*
          One or more revision IDs.

    *Added in:*
          2.1

    *Purpose:*
          Prints all revisions which are ancestors of all of the
          revisions given as arguments.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one common ancestor
          of all the given revisions.  Each line consists of a revision
          ID, in hexadecimal, followed by a newline.  The lines are
          printed in alphabetically sorted order.

          The output will include one of the argument revisions only if
          that revision is an ancestor of all other revisions given as
          arguments.

    *Error conditions:*
          If any of the revisions do not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate content_diff [--revision=ID1 [--revision=ID2]] [--reverse] [FILE...]'

    *Arguments:*
          See the online help for more options.

          One or more FILE arguments restrict the diff output to these
          files, otherwise all changed files in the given revision(s)
          and/or current workspace are considered.

          If zero or more revisions are given, the command behaves as
          follows:

             * no revision: the diff is done from the parent (base)
               revision of this workspace to the workspace revision.

             * one revision: the diff is done from the given revision
               `id1' to the workspace revision. If `--reverse' is
               given, the order is reversed.

             * two revisions: the diff is done from `id1' to `id2'; no
               workspace is needed in this case.

    *Changes:*
             * 9.0 - added `--with-header' option

             * 4.0 - initial

    *Purpose:*
          Prints the content changes between two revisions or a
          revision and the current workspace. This command differs from
          `mtn diff' in that it only outputs content changes and keeps
          quiet on renames or drops by default, as the header of `mtn
          diff' is omitted unless `--with-header' is given and is
          omitted regardless if there are no changes.

    *Sample output:*
          ============================================================
          --- guitone/res/i18n/guitone_de.ts      9857927823e1d6a0339b531c120dcaadd22d25e9
          +++ guitone/res/i18n/guitone_de.ts      0b4715dc296b1955b0707923d45d79ca7769dd3f
          @@ -1,6 +1,14 @@
           <?xml version="1.0" encoding="utf-8"?>
           <!DOCTYPE TS><TS version="1.1">
           <context>
          +    <name>AncestryGraph</name>
          +    <message>
          [...]

    *Output format:*
          The GNU unified diff format. If there have been no content
          changes, the output is empty.

    *Error conditions:*
          If more than two revisions are given or a workspace is
          required, but not found, prints to stderr and exits with
          status 1. If one or more file restrictions can't be applied,
          the command prints to stderr and exits as well.


`mtn automate descendents REV...'

    *Arguments:*
          One or more revision IDs.

    *Added in:*
          0.1

    *Purpose:*
          Prints the descendants of one or more revisions.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one descendant of
          the given revisions.  Each line consists of a revision ID, in
          hexadecimal, followed by a newline.  The lines are printed in
          alphabetically sorted order.

          The output does not include REV..., unless one of them is a
          descendent of another.

    *Error conditions:*
          If any of the revisions do not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate drop_attribute PATH [KEY]'

    *Arguments:*
          A path and an attribute key (optional).

    *Added in:*
          5.0

    *Purpose:*
          Automate variant of `*note mtn attr drop::'.

          Removes an attribute from the current workspace revision for
          the specified path.  If no attribute key is given, all
          attributes of this path are removed. Note that this change is
          not committed.

    *Output format:*
          This command does not print out anything if successful.

    *Error conditions:*
          If the path specified is unknown in the new workspace
          revision or the attribute key is not found for this path,
          prints an error message to stderr and exits with status 1.


`mtn automate drop_db_variables DOMAIN [NAME]'

    *Arguments:*
          The DOMAIN and NAME specify the database variable which
          should be dropped. If NAME is ommitted, all database
          variables in the DOMAIN are dropped.

    *Added in:*
          7.0

    *Purpose:*
          Drops one or more database variables; see *note Vars::.

    *Sample usage:*
          mtn automate drop_db_variables known-servers

    *Output format:*
          No output.

    *Error conditions:*
          If the specific variable or any variables in the given domain
          are not found, prints to stderr and exits with status 1.


`mtn automate drop_public_key KEYID'

    *Arguments:*
          KEYID identifies the key to drop, by name or hash.

    *Changes:*
             * 13.0 - initial


    *Purpose:*
          Drop a public key from the database (_not_ the private key
          from the keystore). Signatures made with the key can no
          longer be verified.

          This command should be used with caution as changes are
          irreversible without a backup of the key(s) that were
          dropped. You may wish to use the `k:' selector to check if
          the key is used in a signature.

          Note that public keys that are used to sign a revision may be
          restored to the database by a future sync.

          Keys in the keystore are not dropped because that is very
          dangerous on a server. The only way to drop private keys on a
          server is via the command `*note mtn dropkey::'.

    *Sample output:*
          None.

    *Output format:*
          None on the main stream; progress message on the progress
          stream.

    *Error conditions:*
          If the key does not exist, an error message is printed on the
          error stream.


`mtn automate erase_ancestors [REV...]'

    *Arguments:*
          One or more revision IDs.

    *Added in:*
          0.1

    *Purpose:*
          Prints all arguments, except those that are an ancestor of
          some other argument.

          One way to think about this is that it prints the minimal
          elements of the given set, under the ordering imposed by the
          "child of" relation.  Another way to think of it is if the
          arguments formed a branch, then we would print the heads of
          that branch.  If there are no arguments, prints nothing.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one of the given
          revisions.  Each line consists of a revision ID, in
          hexadecimal, followed by a newline.  The lines are printed in
          alphabetically sorted order.

    *Error conditions:*
          If any of the revisions do not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate file_merge LEFT-RID LEFT-PATH RIGHT-RID RIGHT-PATH'

    *Arguments:*
          LEFT-RID, LEFT-FID, RIGHT-RID, RIGHT-FID specify two files to
          merge, by revision and file path.

    *Added in:*
          9.0

    *Purpose:*
          Prints the result of the internal line merge on the contents
          of the specified files.

          This command does not just take two file ids, because the
          revision ids and paths are needed to check for manual merge
          and file encoding attributes.

    *Sample output:*
          If you've downloaded a release, see INSTALL for installation
          instructions.  If you've checked this out, the generated files are not
          included, and you must use "autoreconf --install" to create them.

          "make html" for docs, or read the .info file and / or man page.

    *Output format:*
          The file merge results are output without modification.

    *Error conditions:*
          If either revision id is unknown or invalid, or if either
          path does not exist, or if the internal line merger fails,
          prints an error message to stderr and exits with status 1.


`mtn automate generate_key NAME PASSPHRASE'

    *Aguments*
          NAME is the name to associate with the new key, and
          PASSPHRASE is the passphrase that will be used to encrypt the
          private half.

    *Changes:*
             * 13.0 - renamed from `genkey' to `generate_key'

             * 10.0 - The separate hashes for the private half of a key
               really didn't make much sense; have one `hash [...]'
               line instead of separate `public_hash [...]' and
               `private_hash [...]' lines.

             * 3.1 - initial

    *Purpose:*
          Generate a key with the given name and passphrase.

    *Sample output:*
                      name "tbrownaw@gmail.com"
                      hash [475055ec71ad48f5dfaf875b0fea597b5cbbee64]
           public_location "database" "keystore"
          private_location "keystore"

    *Output format:*
          A basic_io stanza. The public_location and private_location
          items may have multiple values as shown above for
          public_location, one value for each place that the key is
          stored.

    *Error conditions:*
          Error conditions: If the passphrase is empty or the key
          already exists, prints an error message to stderr and exits
          with status 1.


`mtn automate get_attributes PATH'

    *Arguments:*
          The argument PATH determines which path's attributes should
          be printed.

    *Changes:*
             * 11.0 - removed the `format_version' stanza

             * 5.0 - renamed from `attributes' to `get_attributes'

             * 3.0 - initial

    *Purpose:*
          Prints all attributes of the given file in the current
          workspace, and the attribute states.

    *Sample output:*
           attr "foo" "bar"
          state "added"

           attr "baz" "bat"
          state "dropped"

           attr "foobar" "foobat"
          state "unchanged"

    *Output format:*
          There is one basic_io stanza for each attribute of the given
          file.

          All stanzas are formatted by basic_io. Stanzas are separated
          by a blank line and ordered by attribute name. Values will be
          escaped, '\' to '\\' and '"' to '\"'.

          Each attribute stanza also contains another entry which tells
          the status of attribute. This entry can have one of the
          following four values:

             * 'added': the attribute has just been added to the file

             * 'dropped': the attribute has just been dropped from the
               file

             * 'unchanged': the attribute has not been changed since
               the last revision

             * 'changed': the attribute has been changed since the last
               revision

          The status 'changed' can come up if an attribute foo has been
          dropped and added afterwards with another value, like

          $ mtn attr drop file.txt foo ; mtn attr set file.txt foo baz

          If an attribute has been dropped, the output will still
          return the previously set value of the dropped attribute for
          convenience (obviously this is no longer recorded in the
          current workspace).

          The complete format:

          'attr':
                represents an attribute.
                format: ('attr', key, value), ('state', [unchanged|changed|added|dropped])
                occurs: zero or more times

    *Error conditions:*
          If the path specified is unknown in the workspace, prints an
          error message to stderr and exits with status 1.


`mtn automate get_base_revision_id'

    *Arguments:*
          None.

    *Added in:*
          2.0

    *Purpose:*
          Prints the base revision id of the current workspace. This is
          the "old_revision" value stored in `_MTN/revision'.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61

    *Output format:*
          One line containing the base revision ID of the current
          workspace.

    *Error conditions:*
          If no workspace is found, prints an error message to stderr,
          and exits with status 1.


`mtn automate get_content_changed REV FILE'

    *Arguments:*
          The REV specifies a revision ID, from which content change
          calculations will be based.  and FILE specifies the file for
          which to calculate revisions in which it was last changed.

    *Added in:*
          4.0

    *Purpose:*
          Returns a list of revision IDs in which the content was most
          recently changed, relative to the revision ID specified as
          REV. This equates to a content mark following the *-merge
          algorithm.

    *Sample output:*
            content_mark [276264b0b3f1e70fc1835a700e6e61bdbe4c3f2f]

    *Output format:*
          Zero or more basic_io stanzas, each specifying a revision ID
          in which a content mark is set:

             * No content mark is returned if FILE is a directory.

             * One content mark is returned if FILE is a file and has
               recently been changed exclusively in one revision (be it
               by a commit or merge).

             * Multiple content marks are returned if FILE is a file
               and has recently been part of a clean merge case.  A
               clean merge happens when the same change to FILE is made
               on both sides of the particular merge, together with
               other unrelated changes, which make the resulting
               revisions not collapse into one revision.

    *Error conditions:*
          If REV or FILE is unknown or invalid prints an error message
          to stderr and exits with status 1.


`mtn automate get_corresponding_path SOURCE_ID FILE TARGET_ID'

    *Arguments:*
          The SOURCE_ID specifies a revision ID in which FILE is extant.
          and FILE specifies the file whose name in TARGET_ID is to be
          determined; TARGET_ID specifies a revision ID.

    *Added in:*
          4.0

    *Purpose:*
          Given a the file name FILE in the source revision SOURCE_ID,
          a filename will if possible be returned naming the file in
          the target revision TARGET_ID.  This allows the same file to
          be matched between revisions, accounting for renames and
          other changes.

    *Sample output:*
          file "foo"

    *Output format:*
          Zero or one basic_io lines. Zero lines will be output if the
          file does not exist within the target revision; this is not
          considered an error. If the file does exist in the target
          revision, a single line is output.

    *Error conditions:*
          If the revision IDs SOURCE_ID or TARGET_ID are unknown or
          invalid prints an error message to stderr and exits with
          status 1. If the file path FILE does not exist in the
          revision SOURCE_ID or is invalid, prints an error message to
          stderr and exits with status 1. Note that FILE not existing
          in the revision TARGET_ID is not an error.


`mtn automate get_current_revision [--exclude EXCL] [--depth=DEPTH] [PATH...]'

    *Arguments:*
          One or more PATH arguments restrict the revision to these
          paths, otherwise all changes in workspace are taken into
          account.

          See online help for more options.

    *Added in:*
          7.0

    *Purpose:*
          Prints change information for the current workspace,
          optionally restricted by one or more paths.

    *Sample output:*
          See `*note mtn automate get_revision::'

    *Output format:*
          See `*note mtn automate get_revision::'

    *Error conditions:*
          If the command is executed outside of a workspace, or the
          restriction is invalid, prints an error message to stderr and
          exits with status 1.


`mtn automate get_current_revision_id'

    *Arguments:*
          None.

    *Added in:*
          2.0

    *Purpose:*
          Prints the revision id of the current workspace. This is the
          id of the revision that would be committed by an unrestricted
          commit in the workspace.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61

    *Output format:*
          One line containing the current revision id ID of the current
          workspace.

    *Error conditions:*
          If no workspace is found, prints an error message to stderr,
          and exits with status 1.


`mtn automate get_db_variables [DOMAIN]'

    *Arguments:*
          The optional DOMAIN restricts the output to variables only
          within this domain.

    *Changes:*
             * 7.0 - converted output to basic_io, renamed to
               'get_db_variables'

             * 4.1 - added as 'db_get'

    *Purpose:*
          Outputs database variable domains, names and values. For more
          information about variables, see *note Vars::.

    *Sample output:*
          domain "database"
           entry "default-exclude-pattern" ""
           entry "default-include-pattern" "net.venge.monotone*"
           entry "default-server" "mtn://code.monotone.ca/monotone"

          domain "known-servers"
           entry "mtn://code.monotone.ca/monotone" "2c88403f0ed546df96ccec57ab3072aa73a05e71"

    *Output format:*
          basic_io-formatted stanzas. Each stanza starts with a
          'domain', followed by one or more 'entry' lines. Each 'entry'
          contains the NAME and the VALUE of the respective database
          variable.

    *Error conditions:*
          If the domain is unknown or no variables where found, prints
          an error message to stderr and exits with status 1.


`mtn automate get_extended_manifest_of REVID'

    *Arguments:*
          The REVID specifies the revision for which the extended
          manifest should be printed.

    *Changes:*
          13.0 - initial

    *Purpose:*
          Prints the contents of the extended manifest associated with
          the given revision.

    *Sample output:*
                dir ""
              birth [0cd607d6dda3a2df18f777112947f3c70811581e]
          path_mark [0cd607d6dda3a2df18f777112947f3c70811581e]

                   dir "dir"
          dormant_attr "dirprop"
                 birth [0cd607d6dda3a2df18f777112947f3c70811581e]
             path_mark [0cd607d6dda3a2df18f777112947f3c70811581e]
             attr_mark "dirprop" [a7a71d7cc0d526165e7362b8a87393d8609f40c2]

                  file "file"
               content [d3395867d05cc4c27f013d6e6f48d644e96d8241]
                  size "8"
                  attr "fileprop" "value"
                 birth [0cd607d6dda3a2df18f777112947f3c70811581e]
             path_mark [0cd607d6dda3a2df18f777112947f3c70811581e]
          content_mark [a7a71d7cc0d526165e7362b8a87393d8609f40c2]
             attr_mark "fileprop" [a7a71d7cc0d526165e7362b8a87393d8609f40c2]

    *Output format:*
          There is one basic_io stanza for each file or directory in the
          extended manifest.

          The 'dir' and 'file' lines are the first in every stanza and
          specify its type as follows:

          'dir':
                Represents a directory.  The path "" (the empty string) is used
                to represent the root of the tree.
                format: ('dir', pathname)
                occurs: one or more times
          'file':
                Represents a file.
                format: ('file', pathname)
                occurs: zero or more times

          In addition, both 'dir' and 'file' stanzas include more
          information on the particular node:

          'birth':
                The revision id in which the node was added ("born").
                format: ('birth', revision id)
                occurs: once per node
          'path_mark':
                The revision id in which the node was last renamed.
                format: ('path_mark', revision id)
                occurs: once per node
          'content':
                The id of the file node, i.e. the hash of its contents.
                format: ('content', file id)
                occurs: once per file node
          'content_mark':
                The revision id in which the node's content was changed at last.
                format: ('content_mark', revision id)
                occurs: once per file node
          'size':
                The recorded file size, in bytes.
                format: ('size', size in bytes)
                occurs: once per file node

          Finally, attributes are also part of the format:

          'attr':
                The name and the value of a specific attribute.
                format: ('attr', attribute name, attribute value)
                occurs: zero or more times per node
          'dormant_attr':
                The name of a previously deleted attribute.
                format: ('dormant_attr', attribute name)
                occurs: zero or more times per node
          'attr_mark':
                The revision id in which a particular attribute's value was
                changed at last.
                format: ('attr_mark', attribute name, revision id)
                occurs: zero or more times per node

          All stanzas are sorted by the path string.

    *Error conditions:*
          If the revision ID specified is unknown or invalid prints an
          error message to stderr and exits with status 1.


`mtn automate get_file ID'

    *Arguments:*
          The ID argument specifies the file hash of the file to be
          output.

    *Added in:*
          1.0

    *Purpose:*
          Prints the contents of the specified file.

    *Sample output:*
          If you've downloaded a release, see INSTALL for installation
          instructions.  If you've checked this out, the generated files are not
          included, and you must use "autoreconf --install" to create them.

          "make html" for docs, or read the .info file and / or man page.

    *Output format:*
          The file contents are output without modification.

    *Error conditions:*
          If the file id specified is unknown or invalid prints an
          error message to stderr and exits with status 1.


`mtn automate get_file_of FILENAME [--revision=ID]'

    *Arguments:*
          The FILENAME argument specifies the filename of the file to
          be output.

          If a revision ID is given, the file's contents in that
          specific revision are printed. If no revision is given, the
          workspace base revision is used.

    *Added in:*
          4.0

    *Purpose:*
          Prints the contents of the specified file.

    *Sample output:*
          If you've downloaded a release, see INSTALL for installation
          instructions.  If you've checked this out, the generated files are not
          included, and you must use "autoreconf --install" to create them.

          "make html" for docs, or read the .info file and / or man page.

    *Output format:*
          The file contents are output without modification.

    *Error conditions:*
          If the filename specified is unknown in the given revision or
          invalid, or if the given revision is unknown, prints an error
          message to stderr and exits with status 1.


`mtn automate get_file_size ID'

    *Arguments:*
          The ID argument specifies the file hash of the file for which
          the size should be printed.

    *Changes:*
          13.0 - initial

    *Purpose:*
          Prints the recorded file size of the specified file.

          If you need to know the file sizes of multiple files of the
          same revision, its usually faster to use the `*note mtn
          automate get_extended_manifest_of::' command.

    *Sample output:*
          1241

    *Output format:*
          The size of the file in bytes followed by a linefeed
          character ('\n').

    *Error conditions:*
          If the file id specified is unknown or invalid prints an
          error message to stderr and exits with status 1.


`mtn automate get_manifest_of [REVID]'

    *Arguments:*
          Specifying the optional REVID argument outputs the manifest
          for the revision with the specified ID. Otherwise, outputs
          the manifest for the current workspace.

    *Added in:*
          2.0

    *Purpose:*
          Prints the contents of the manifest associated with the given
          revision.

    *Sample output:*
          format_version "1"

          dir ""

             file ".htaccess"
          content [e3915658cb464d05f21332e03d30dca5d94fe776]

             file "AUTHORS"
          content [80d8f3f75c9b517ec462233e155f7dfb93379f67]

             file "ChangeLog"
          content [fc74a48c7f73eedcbe1ea709755fbe819b29736c]

    *Output format:*
          There is one basic_io stanza for each file or directory in the
          manifest.

          'format_version'
                used in case this format ever needs to change.
                format: ('format_version', the string "1")
                occurs: exactly once
          'dir':
                represents a directory.  The path "" (the empty string) is used
                to represent the root of the tree.
                format: ('dir', pathname)
                occurs: one or more times
          'file':
                represents a file.
                format: ('file', pathname), ('content', file id)
                occurs: zero or more times

          In addition, 'dir' and 'file' stanzas may have attr
          information included.  These are appended to the stanza below
          the basic dir/file information, with one line describing each
          attr.  These lines take the form ('attr', attr name, attr
          value).

          Stanzas are sorted by the path string.

    *Error conditions:*
          If the revision ID specified is unknown or invalid prints an
          error message to stderr and exits with status 1.


`mtn automate get_option OPTION'

    *Arguments:*
          The OPTION argument specifies the option name of the option
          to be output.

    *Added in:*
          3.1

    *Purpose:*
          Prints an option from `_MTN/option' of the current workspace.

    *Sample output:*
          net.venge.monotone

    *Output format:*
          The option value is written out without modification.

    *Error conditions:*
          If the option is unknown, prints an error message to stderr
          and exits with status 1.


`mtn automate get_public_key KEYID'

    *Arguments:*
          KEYID identifies the key to display, by name or hash.

    *Added in:*
          13.0

    *Purpose:*
          Same as `*note mtn pubkey::'; print the key in packet format,
          suitable for reading by `*note mtn automate put_public_key::'.

    *Sample output:*
          [pubkey foo@bar.com]
          MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQs4OEcqULwepphO5Rsb/aSLpiEryGtEkQRNQPNFxvcu1rwVnNKRxep1KCDrwV3se9f4hUQ8zz73NQggS82guSI/YuyXZDZHrw+v3YgAMV/mKGnAjgYnyRNUL1xCywV7fnqTduBBqkDEVSCqphWlii/gFB/PVo4sbJ4Hk7O6ujWwIDAQAB
          [end]

    *Output format:*
          See example.

    *Error conditions:*
          If the key does not exist, an error message is printed on the
          error stream.


`mtn automate get_revision ID'

    *Arguments:*
          The argument ID specifies the revision id for which the
          changeset information should be printed.

    *Changes:*
             * 7.0 - ID is now mandatory

             * 1.0 - initial

    *Purpose:*
          Prints change information for the specified revision id.

    *Sample output:*
          format_version "1"

          new_manifest [bfe2df785c07bebeb369e537116ab9bb7a4b5e19]

          old_revision [429fea55e9e819a046843f618d90674486695745]

          patch "ChangeLog"
           from [7dc21d3a46c6ecd94685ab21e67b131b32002f12]
             to [234513e3838d423b24d5d6c98f70ce995c8bab6e]

          patch "std_hooks.lua"
           from [0408707bb6b97eae7f8da61af7b35364dbd5a189]
             to [d7bd0756c48ace573926197709e53eb24dae5f5f]

    *Output format:*
          There are several changes that are described; each of these
          is described by a different basic_io stanza. The first string
          pair of each stanza indicates the type of change represented.

          'format_version'
                used in case this format ever needs to change.
                format: ('format_version', the string "1")
                occurs: exactly once
          'new_manifest'
                represents the new manifest associated with the revision.
                format: ('new_manifest', manifest id)
                occurs: exactly one
          'old_revision'
                represents a parent revision.
                format: ('old_revision', revision id)
                occurs: either one or two times
          'delete
                represents a file or directory that was deleted.
                format: ('delete', path)
                occurs: zero or more times
          'rename'
                represents a file or directory that was renamed.
                format: ('rename, old filename), ('to', new filename)
                occurs: zero or more times
          'add_dir'
                represents a directory that was added.
                format: ('add_dir, path)
                occurs: zero or more times
          'add_file'
                represents a file that was added.
                format: ('add_file', path), ('content', file id)
                occurs: zero or more times
          'patch'
                represents a file that was modified.
                format: ('patch', filename), ('from', file id), ('to', file id)
                occurs: zero or more times
          'clear'
                represents an attr that was removed.
                format: ('clear', filename), ('attr', attr name)
                occurs: zero or more times
          'set'
                represents an attr whose value was changed.
                format: ('set', filename), ('attr', attr name), ('value', attr value)
                occurs: zero or more times

          These stanzas will always occur in the order listed here;
          stanzas of the same type will be sorted by the filename they
          refer to. The 'delete' and following stanzas will be grouped
          under the corresponding 'old_revision' one.

    *Error conditions:*
          If the revision specified is unknown or invalid prints an
          error message to stderr and exits with status 1.


`mtn automate get_workspace_root'

    *Arguments:*
          None.

    *Added in:*
          8.0

    *Purpose:*
          Print the path of the workspace root for the current
          directory.

    *Sample output:*
          /home/jim/juice

    *Output format:*
          A path.

    *Error conditions:*
          If the current directory isn't part of a workspace, prints an
          error to stderr and exits with status 1.


`mtn automate graph'

    *Arguments:*
          None.

    *Added in:*
          0.2

    *Purpose:*
          Prints out the complete ancestry graph of this database.

    *Sample output:*
          0c05e8ec9c6af4224672c7cc4c9ef05ae8bdb794
          27ebcae50e1814e35274cb89b5031a423c29f95a 5830984dec5c41d994bcadfeab4bf1bf67747b89
          4e284617c80bec7da03925062a84f715c1b042bd 27ebcae50e1814e35274cb89b5031a423c29f95a 657c756d24fb65213d59f4ae07e117d830dcc95b

    *Output format:*
          Zero or more lines, each giving ancestry information for one
          revision.  Each line begins with a revision ID.  Following
          this are zero or more space-prefixed revision IDs.  Each
          revision ID after the first is a parent (in the sense of
          `*note mtn automate parents::') of the first.  For instance,
          in the above sample output,
          0c05e8ec9c6af4224672c7cc4c9ef05ae8bdb794 is a root node,
          27ebcae50e1814e35274cb89b5031a423c29f95a has one parent, and
          4e284617c80bec7da03925062a84f715c1b042bd has two parents,
          i.e., is a merge node.

          The output as a whole is alphabetically sorted by line;
          additionally, the parents within each line are alphabetically
          sorted.

    *Error conditions:*
          None.


`mtn automate heads [BRANCH]'

    *Arguments:*
          One branch name. If none is given, the workspace branch is
          used.

    *Added in:*
          0.0

    *Purpose:*
          Prints the heads of branch BRANCH.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one head of the
          given branch.  Each line consists of a revision ID, in
          hexadecimal, followed by a newline.  The lines are printed in
          alphabetically sorted order.

    *Error conditions:*
          If the given branch does not exist, an error message is
          printed.


`mtn automate identify PATH'

    *Arguments:*
          A file path.

    *Added in:*
          4.3

    *Purpose:*
          Prints the file ID (aka hash) of the given file.

    *Sample output:*
          6265ab1312fbe38bdc3aafa92441139cb2b779b0

    *Output format:*
          A single line with the file's ID, in hexadecimal, followed by
          a newline.

    *Error conditions:*
          If the file does not exist, is a special file or not
          readable, prints an error message to stderr and exits with
          status 1. A single file path only consisting of "-" is
          disallowed since it collides with the UNIX stdin marker.


`mtn automate interface_version'

    *Arguments:*
          None.

    *Added in:*
          0.0

    *Purpose:*
          Prints version of the automation interface.  Major number
          increments whenever a backwards incompatible change is made
          to any automate command; minor number increments whenever any
          change is made (but is reset when major number increments).

    *Sample output:*
          1.2

    *Output format:*
          A decimal number, followed by "." (full stop/period),
          followed by a decimal number, followed by a newline.  The
          first decimal number is the major version, the second is the
          minor version.

    *Error conditions:*
          None.


`mtn automate inventory [`options...'] [FILES...]'

    *Arguments:*
          One or more file paths (optional). If present, only show an
          inventory for the given files or directories (and their
          sub-directories); otherwise, show an inventory for the
          current workspace.

         `--depth=N'
               Maximum number of directories to descend.

         `--exclude=EXCLUDE-GLOB'
               File or directory to exclude.

         `--[no-]corresponding-renames'
               If restricted to a renamed path, do not output the
               corresponding old / new paths for this restriction.

         `--[no-]ignored'
               Don't output ignored files or directories.

         `--[no-]unchanged'
               Don't output files that are known but not changed in any
               way.

         `--[no-]unknown'
               Don't output unknown directories.


    *Changes:*
             * 8.0 - added the output of the `birth' key

             * 7.0 - added options `--no-ignored', `--no-unknown',
               `--no-unchanged' and `--no-corresponding-renames'

             * 6.0 - converted to basic_io format (restriction support,
               various fixes)

             * 1.0 - initial, line-based format

    *Purpose:*
          Prints information on every file found in the workspace or its
          associated base and revision manifests.

    *Sample output:*
          All basic status cases:     path "added"
          new_type "file"
           fs_type "file"
            status "added" "known"
           changes "content"

              path "attributes_altered"
          old_type "file"
          new_type "file"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "known"
           changes "attrs"

              path "dropped"
          old_type "file"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "dropped"

             path "ignored~"
          fs_type "file"
           status "ignored"

              path "missing"
          old_type "file"
          new_type "file"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "missing"

              path "original"
          old_type "file"
          new_path "renamed"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source"

              path "patched"
          old_type "file"
          new_type "file"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "known"
           changes "content"

              path "patched_and_attributes_altered"
          old_type "file"
          new_type "file"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "known"
           changes "content" "attrs"

              path "renamed"
          new_type "file"
          old_path "original"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "known"

              path "unchanged"
          old_type "file"
          new_type "file"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "known"

             path "unknown"
          fs_type "file"
           status "unknown"

          Two files swapped in both the revision manifest and the
          workspace:     path "original"
          old_type "file"
          new_path "unchanged"
          new_type "file"
          old_path "unchanged"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"

              path "unchanged"
          old_type "file"
          new_path "original"
          new_type "file"
          old_path "original"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"

          Recorded in the revision manifest that two files were
          swapped, but they were not actually swapped in the workspace.
          Thus they both appear as patched:     path "original"
          old_type "file"
          new_path "unchanged"
          new_type "file"
          old_path "unchanged"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"
           changes "content"

              path "unchanged"
          old_type "file"
          new_path "original"
          new_type "file"
          old_path "original"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"
           changes "content"

          Rename (in the manifest and the workspace) `foo' to `bar';
          add (in the manifest and the workspace) new file `foo':     path "foo"
          old_type "file"
          new_path "bar"
          new_type "file"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "added" "known"

              path "bar"
          new_type "file"
          old_path "foo"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "known"

          Rotated files `foo' -> `bar' -> `baz' -> `foo' (in the
          manifest and the workspace):     path "foo"
          old_type "file"
          new_path "bar"
          new_type "file"
          old_path "baz"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"

              path "bar"
          old_type "file"
          new_path "baz"
          new_type "file"
          old_path "foo"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"

              path "baz"
          old_type "file"
          new_path "foo"
          new_type "file"
          old_path "bar"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"

          Recorded in the revison manifest the rotation of files `foo'
          -> `bar' -> `baz' -> `foo', but the actual files in the
          workspace were not moved, so monotone interprets all files as
          having been patched:     path "foo"
          old_type "file"
          new_path "bar"
          new_type "file"
          old_path "baz"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"
           changes "content"

              path "bar"
          old_type "file"
          new_path "baz"
          new_type "file"
          old_path "foo"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"
           changes "content"

              path "baz"
          old_type "file"
          new_path "foo"
          new_type "file"
          old_path "bar"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "rename_target" "known"
           changes "content"

          Dropped from the manifest but not removed in the workspace
          and thus unknown:     path "dropped"
          old_type "file"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "dropped" "unknown"

          Added in the manifest but not in the workspace, and thus
          missing:     path "added"
          new_type "file"
           fs_type "none"
            status "added" "missing"

          Recorded a rename in the manifest, but not moved in the
          workspace, and thus unknown source and missing target:     path "original"
          old_type "file"
          new_path "renamed"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source" "unknown"

              path "renamed"
          new_type "file"
          old_path "original"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "missing"

          Moved in the workspace but no rename recorded in the
          manifest, and thus missing source and unknown target:     path "original"
          old_type "file"
          new_type "file"
           fs_type "none"
            status "missing"

             path "renamed"
          fs_type "file"
           status "unknown"

          Renamed in the manifest and the workspace and patched:     path "original"
          old_type "file"
          new_path "renamed"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source"

              path "renamed"
          new_type "file"
          old_path "original"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "known"
           changes "content"

          Renamed and restricted to `original' or `renamed':     path "original"
          old_type "file"
          new_path "renamed"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source"

              path "renamed"
          new_type "file"
          old_path "original"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "known"
           changes "content"

          Renamed and restricted to `original' with the
          `--no-corresponding-renames' option:     path "original"
          old_type "file"
          new_path "renamed"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source"

          Renamed and restricted to `renamed' with the
          `--no-corresponding-renames' option:     path "renamed"
          new_type "file"
          old_path "original"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "known"
           changes "content"

          File is missing, an unversioned directory is in the way:     path "missing_file"
          old_type "file"
          new_type "file"
           fs_type "directory"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "invalid"
           changes "content"

          Directory is missing, an unversioned file is in the way:     path "missing_directory"
          old_type "directory"
          new_type "directory"
           fs_type "file"
            status "invalid"

          Directory `source' renamed to `target', `target' is missing,
          an unversioned file is in the way:     path "source"
          old_type "directory"
          new_path "target"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source"

              path "source/a"
          old_type "file"
          new_path "target/a"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_source"

              path "target"
          new_type "directory"
          old_path "source"
           fs_type "file"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "invalid"

              path "target/a"
          new_type "file"
          old_path "source/a"
           fs_type "none"
             birth [cb271687054afd3c2b873c8994f206f08fb240d3]
            status "rename_target" "missing"

    *Output format:*
          Each path is printed in one basic_io stanza. Stanzas are
          separated by a blank line. Each stanza starts with a `path'
          line, and contains up to seven lines.

         `path'
               The file or directory path, relative to the workspace
               root. The file either exists in the workspace, or is
               listed in the base or revision manifest.  `path' is
               always output.

         `old_type'
               The type of the node in the base manifest.  "type" is
               either `file' or `directory'.  `old_type' is output for
               all old nodes (i.e. unchanged or dropped paths and
               rename sources).

         `new_type'
               The type of the node in the revision manifest.  "type"
               is either `file' or `directory'.  `new_type' is output
               for all new nodes (i.e. unchanged or added paths and
               rename targets).

         `fs_type'
               The type of the node in the workspace (also called the
               filesystem).  "type" is either `file', `directory' or
               `none' (if the path does not exist in the file system).
               `fs_type' is always output.

         `old_path'
               The old path for the node, if it has been renamed in the
               revision manifest.  `old_path' is only output for rename
               targets.

         `new_path'
               The new path for the node, if it has been renamed in the
               revision manifest.  `new_path' is only output for rename
               sources.

         `birth'
               The identify of the revision that the node was first
               added in.  `birth' is only output if it exists in a
               committed revision.

         `status'
               `status' is always output. Its value is one or more of:

              `rename_source'
                    PATH is part of a rename and denotes the old name
                    of a renamed node.

              `rename_target'
                    PATH is part of a rename and denotes the new name
                    of a renamed node.

              `added'
                    PATH has been added in the revision manifest, but
                    not existent in the base manifest.

              `dropped'
                    PATH has been deleted in the revision manifest and
                    the workspace.

              `missing'
                    PATH has been deleted in the workspace, but still
                    exists in the revision manifest.

                    A file will also be labeled `missing' if it is in a
                    directory that is ignored due to a regular
                    expression in `.mtn-ignore', but is also in the
                    revision manifest. A warning is issued in this case.

              `ignored'
                    PATH is ignored by monotone.

              `known'
                    PATH exists in the workspace, and in the revision
                    manifest.

              `unknown'
                    PATH exists in the workspace, but not in the
                    revision manifest, i.e.  is unversioned.

              `invalid'
                    PATH is versioned and exists in the workspace and
                    revision manifest, but with incompatible types (a
                    versioned missing file is replaced by an
                    unversioned directory and vice versa).

         `changes'

              `content'
                    The contents of a file have been changed.

              `attrs'
                    The attributes of a path (file or directory) have
                    been changed.


    *Error conditions:*
          When executed from outside of a workspace directory, prints
          an error message to stderr, and exits with status 1.


`mtn automate keys'

    *Arguments:*
          None.

    *Changes:*
             * 11.0 - Instead of having a "name" item, there are
               "given_name" and "local_name" items.

             * 10.0 - The separate hashes for the private half of a key
               really didn't make much sense; have one `hash [...]'
               line instead of separate `public_hash [...]' and
               `private_hash [...]' lines.

             * 1.1 - initial


    *Purpose:*
          Print all keys in basic_io format.

    *Sample output:*
                      hash [475055ec71ad48f5dfaf875b0fea597b5cbbee64]
                given_name "tbrownaw@gmail.com"
                local_name "tbrownaw@gmail.com"
           public_location "database" "keystore"
          private_location "keystore"

                     hash [3ac4afcd86af28413b0a23b7d22b9401e15027fc]
                given_name "tomfa@debian.org"
                local_name "tomfa@debian.org"
          public_location "database"

                      hash [115fdc73d87a5e9901d018462b21a1f53eca33a1]
                given_name "underwater@fishtank.net"
                local_name "underwater@fishtank.net"
           public_location "keystore"
          private_location "keystore"

    *Output format:*
          For each key, a basic_io stanza is printed. The
          public_location and private_location items may have multiple
          values as shown above for public_location, one value for each
          place that the key is stored. If the private key does not
          exist, then the private_hash and private_location items will
          be absent. given_name is the name provided when the key was
          created, and local_name is the name returned by the `*note
          get_local_key_name::' hook.

          The keys are ordered by hash value.

    *Error conditions:*
          None.


`mtn automate leaves'

    *Arguments:*
          None.

    *Added in:*
          0.1

    *Purpose:*
          Prints the leaves of the revision graph, i.e. all revision
          that have no children.

          This is similar, but not identical to the functionality of
          `*note mtn automate heads::', which prints every revision in a
          branch, that has no descendants in that branch.  If every
          revision in the database was in the same branch, then they
          would be identical.  Generally, every leaf is the head of
          some branch, but not every branch head is a leaf.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each a leaf of the revision graph.  Each
          line consists of a revision ID, in hexadecimal, followed by a
          newline.  The lines are printed in alphabetically sorted
          order.

    *Error conditions:*
          None.


`mtn automate log [OPTIONS] [PATHNAME...]'

    *Arguments:*
          [-depth=N] [-exclude=PATH...]  [-last=N] [-next=N]
          [-from=ID...]  [-clear-from] [-to=ID...] [-clear-to]
          [-[no-]merges] [PATHNAME...]

          Same as `mtn log', but without the output control options; see
          `*note mtn log::'.

    *Added in:*
          12.2

    *Purpose:*
          Print the selected revisions on stdout, in topological order.
          The user can then use other automate commands to retrieve
          additional information about each revision.

    *Sample output:*
          233afb8c4832bf33d5f5734225164de5f5a6278c
          4a368a6b217c40b2ff3b12bb7cfa00987e0f191c
          233afb8c4832bf33d5f5734225164de5f5a6278c

    *Output format:*
          One revision per line.

    *Error conditions:*
          See `*note mtn log::'.


`mtn automate lua FUNCTION_NAME [FUNCTION_ARGS...]'

    *Arguments:*
          A valid Lua function name and zero or more function
          arguments. Note that string arguments need to be wrapped in
          another pair of quotes, i.e. `"foo"' or `'foo'' will not
          work, but `"'foo'"' or `'"foo"'' will.

          A function arguments can be any valid Lua expression,
          including nested tables and functions, like f.e.
          `{1,true,{['func'] = function(...) return ... end }}'

    *Added in:*
          9.0

    *Purpose:*
          Call Lua functions, like monotone hooks, in the monotone
          context, f.e. to retrieve user defaults like keys, passwords,
          ignorable files and more.

    *Output format:*
          A string dump of the return value of the function, in Lua
          code. The Lua types `function', `thread', `userdata' and
          `lightuserdata' are not serialized, but set to `nil' in the
          dump.

          Please note that `nil' values in tables are not printed since
          Lua does not distinguish between unset and not existing
          entries in a table like other programming languages do.

    *Sample output:*
          A single string return value:

          [1] = "Output";

          Two numeric return values:

          [1] = 3;
          [2] = 4.4;

          A nested table:

          [1] = {
              ["bar"] = {
                  [1] = 1;
                  [2] = 2;
                  [3] = 3;
              };
          };

          A callback function:

          [1] = nil --[[function]];

    *Error conditions:*
          This command prints an error message and exists with status 1
          if the function does not exist, one or more function
          arguments could not be evaluated or the function could not be
          called for another reason.


`mtn automate packet_for_fdata ID'

    *Arguments:*
          The ID specifies the file for which to output an fdata packet.

    *Added in:*
          2.0

    *Purpose:*
          Prints the file data in packet format

    *Sample output:*
          [fdata 229c7f621b65f7e4970ae5aaec993812b9daa1d4]
          H4sIAAAAAAAA/z2OO27DMBBEe51ioMaNrJzBpQAjTXKBBTW0CJPcgFw6yO1DCkG62Q/em83j
          R9vlRez6naPKzh2CwkipXFBJbO8fn7f7HV4LQq4mMYoFzdMYSnMj1xXY/lnuoHt2kB2hQpst
          PREPZhaxvvchskIKkdU6xsXWvQsk76MOUquGVolZmmmh0+xxvf7JZ5jCFXbU4KZ1muYkT+Kw
          FOez5q6uLuh9+9eoQawhez3Fp+VtHJNkfMmDHfALzWYfcAgBAAA=
          [end]

    *Output format:*
          File data in `*note mtn read::' compatible packet format.

    *Error conditions:*
          If ID is unknown or invalid prints an error message to stderr
          and exits with status 1.


`mtn automate packet_for_fdelta FROM-ID TO-ID'

    *Arguments:*
          FROM-ID specifies the file to use as the base of the delta,
          and TO-ID specifies the file to use as the target of the
          delta.

    *Added in:*
          2.0

    *Purpose:*
          Prints the file delta in packet format.

    *Sample output:*
          [fdelta 597049a62d0a2e6af7df0b19f4945ec7d6458727
                  229c7f621b65f7e4970ae5aaec993812b9daa1d4]
          H4sIAAAAAAAA/0WOy0oEMRBF9/mKS2/c9LQg4t5lw+BGf6BIKtNhkpSkKop/b9II7m49OOfu
          eHp5dnvEj/SHL0aQ75qFAgcQGmcm5RXKjP3t/eP1ekWUhlTVKGeyJNXNoXU/s27AP8sf7O8D
          ZEdSSLd1JMaNKzeysY8ps4Iao4oNjM99eFdQDbMOSldDV8ZC3aSxlxpxufzJF5jANx6oyS2b
          c0uhO+OwkpezZhCvK0bf8TVrMLZUo5zi0/I4j4UqPunGA+B+AfHvKEIPAQAA
          [end]

    *Output format:*
          File delta data in `*note mtn read::' compatible packet
          format.

    *Error conditions:*
          If FROM-ID or TO-ID is unknown or invalid prints an error
          message to stderr and exits with status 1.


`mtn automate packet_for_rdata ID'

    *Arguments:*
          The ID specifies the revision to output an rdata packet for.

    *Added in:*
          2.0

    *Purpose:*
          Prints the revision data in packet format

    *Sample output:*
          [rdata bdf3b10b5df0f17cc6c1b4b3351d84701bda59ed]
          H4sIAAAAAAAA/0XQS27DMAwE0L1PIfgArb4kte62NzACg5SoJEBsF7aRurev0UVzgJl5mLas
          E+/jU9ftvsymd33Xzfo9Tjzfm267GSgGwVarz6Valx0KtFYwii9VqUFCqJQ5X7puedRx1ef9
          r2rwHlSbi+BUSrF4xn1p0RInkmxTbmwREp/BL97LzfQfN56v+rlc+860dZnMED01jhILkURJ
          Ul0KPpGN1ueUwDHyiXF66Ywx+2IGD+0Uqg8aCzikAEzZNRXPmJKlkhMxSHuNzrofx/uq2/J4
          6njV/bZsu/zMPOlbOY4XJSD5KOrwXGdwpDGdfotZayQHKTAi5fRPqUWKcAMMIQfAjOK0nkfm
          6tFacjYgBPV46X4BtlpiNYUBAAA=
          [end]

    *Output format:*
          Revision data in `*note mtn read::' compatible packet format.

    *Error conditions:*
          If ID is unknown or invalid prints an error message to stderr
          and exits with status 1.


`mtn automate packets_for_certs ID'

    *Arguments:*
          The ID specifies the revision for which to output cert
          packets.

    *Added in:*
          2.0

    *Purpose:*
          Prints the certs associated with a revision in packet format

    *Sample output:*
          [rcert bdf3b10b5df0f17cc6c1b4b3351d84701bda59ed
                 branch
                 njs@pobox.com
                 bmV0LnZlbmdlLm1vbm90b25l]
          K90i1XHHmaMEMuwbPifFweLThJl0m7jigh2Qq6Z7TBwNJ6IMOjXWCizv73cacZ1CtzxFDVwQ
          SlqhNWiPQWxdcMp+Uuo+V8IFMKmvxVSTuVDukLMuNAQqpGL5S+a+tEj68NMq+KLKuL8kAAPc
          RoFD7GQlTS35S3RHWA4cnvqn+8U=
          [end]
          [rcert bdf3b10b5df0f17cc6c1b4b3351d84701bda59ed
                 date
                 njs@pobox.com
                 MjAwNi0wNC0wOFQxMTo1MDowMA==]
          araz9A8x6AlK6m6UhwnhUhk7cdyxeE2nvzj2gwaDvkaBxOq4SN23/wnaPqUXx1Ddn8smzyRY
          HN08xloYc0yNChp3wjbqx20REcsTg3XE4rN/sgCbqqw5hVT22a5ZhqkfkDeoeJvan0R0UBax
          ngKYo9eLuABNlmFX2onca75JW1E=
          [end]
          [rcert bdf3b10b5df0f17cc6c1b4b3351d84701bda59ed
                 author
                 njs@pobox.com
                 bmpzQHBvYm94LmNvbQ==]
          BLPOYhgLsAN+w7CwOsv9GfXnG3u7RNF1DTrWdn0AnYE1e+ptgTeMVWUI18H4OGL0B7wm08rv
          Pxk/hvsb8fBn1Kf5HDDO2pbjJ0xVzI9+p+TR0y5jJNZlVSTj+nvtPgvK9NzsdooYWnwlWmJv
          bOkAzQcZb8NMh8pbQkdHbR5uzMo=
          [end]
          [rcert bdf3b10b5df0f17cc6c1b4b3351d84701bda59ed
                 changelog
                 njs@pobox.com
                 MjAwNi0wNC0wOCAgTmF0aGFuaWVsIFNtaXRoICA8bmpzQHBvYm94LmNvbT4KCgkqIG5ldHh4
          L3Jlc29sdmVfZ2V0aG9zdGJ5bmFtZS5jeHggKHJlc29sdmVfaG9zdG5hbWUpOiAjaWZkZWYg
          b3V0CglXaW4zMi1pbmNvbXBhdGlibGUgZXJyb3IgcmVwb3J0aW5nIGNhbGwuCg==]
          Ncl4L/oEPctzVQixTKA6FrLceeHnLiXfeyeFDNmtUFYg9BMUcjWkeyKmaWknLvOcHortxjto
          K6pQ9E8S7zI+TpzFAhssg5a///rFL0+2GJU3t6pcHs6LC0Q4tbqzwKd/5+8GwT1gphbM1wm7
          KuzKthwqD3pp49GbgTrp8iWMTr0=
          [end]

    *Output format:*
          Cert data in `*note mtn read::' compatible packet format.

    *Error conditions:*
          If ID is unknown or invalid prints an error message to stderr
          and exits with status 1.


`mtn automate parents REV'

    *Arguments:*
          One revision ID.

    *Added in:*
          0.2

    *Purpose:*
          Prints the immediate parents of a revision.  This is like a
          non-recursive version of `*note mtn automate ancestors::'.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one parent of the
          given revision.  Each line consists of a revision ID, in
          hexadecimal, followed by a newline.  The lines are printed in
          alphabetically sorted order.

    *Error conditions:*
          If the given revision REV does not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate pull [--[no-]set-default] [--dry-run] [URI]'
`mtn automate push [--[no-]set-default] [--dry-run] [--keys-to-push=KEY] [URI]'
`mtn automate sync [--[no-]set-default] [--dry-run] [--keys-to-push=KEY] [URI]'
`mtn automate pull [--[no-]set-default] [ADDRESS] [GLOB [...] [--exclude=EXCLUDE-GLOB]]] *deprecated*'
`mtn automate push [--[no-]set-default] [--keys-to-push=KEY] [ADDRESS] [GLOB [...] [--exclude=EXCLUDE-GLOB]]] *deprecated*'
`mtn automate sync [--[no-]set-default] [--keys-to-push=KEY] [ADDRESS] [GLOB [...] [--exclude=EXCLUDE-GLOB]]] *deprecated*'

    *Arguments:*
          The automate versions of pull, push and sync have the same
          set of arguments and options as the non-automate versions.
          See *note Network:: for a full explanation.

    *Changes:*
             * 13.0 - add sent/received revision, cert, and key output;
               add -dry-run.

             * 12.0 - added

    *Purpose:*
          Pushes, pulls or syncs (push & pull) revisions, certificates
          and keys of the given database to, from or with the given
          netsync server.

    *Sample output:*
          The following is example main channel data, non-dry-run: receive_cert "test"
                 value "value"
                   key [05c26b6cb109ca39bc48bbbdce83564c97796155]
              revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

          receive_revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

           receive_cert "branch"
                  value "foo"
                    key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
               revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

           receive_cert "changelog"
                  value "R1
          "
                    key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
               revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

           receive_cert "date"
                  value "2010-09-01T12:00:00"
                    key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
               revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

           receive_cert "author"
                  value "tester@test.net"
                    key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
               revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

          receive_key [111808abc306fd7423b564f2a8ef5c09745b87d2]

          send_cert "test"
              value "value"
                key [05c26b6cb109ca39bc48bbbdce83564c97796155]
           revision [114f6aa58c7707bf83516d4080ca6268c36640ad]

          send_revision [2a46f4b909071fae756b4911a247ce3ff1c3c4ce]

          send_cert "branch"
              value "foo2"
                key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
           revision [2a46f4b909071fae756b4911a247ce3ff1c3c4ce]

          send_cert "changelog"
              value "R2
          "
                key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
           revision [2a46f4b909071fae756b4911a247ce3ff1c3c4ce]

          send_cert "date"
              value "2010-09-01T12:00:00"
                key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
           revision [2a46f4b909071fae756b4911a247ce3ff1c3c4ce]

          send_cert "author"
              value "tester@test.net"
                key [46ec58576f9e4f34a9eede521422aa5fd299dc50]
           revision [2a46f4b909071fae756b4911a247ce3ff1c3c4ce]

          send_key [05c26b6cb109ca39bc48bbbdce83564c97796155]

          The following is example dry-run main channel data:         estimate
          receive_revision "0"
              receive_cert "0"
               receive_key "0"
             send_revision "1"
                 send_cert "5"
                  send_key "0"
               send_branch "foo2" "1"

          The following shows the progress and ticker data for a pull
          which transferred two revisions and eight certs.

          _Note:_ The linebreaks are not part of the actual format, but
          have been added for better readability.

          0:p:62:doing anonymous pull; use -kKEYNAME if you need authentication
          0:p:46:connecting to mtn://code.monotone.ca/monotone0:0:p:29:finding items to synchronize:
          0:t:34:c:certificates;k:keys;r:revisions;
          0:t:12:c=0;k=0;r=0;
          0:t:13:c#0;k#0;r#64;
          0:t:14:c#0;k#0;r#128;
          [...]
          0:t:6:c;k;r;
          0:t:44:>:bytes in;<:bytes out;c:certs in;r:revs in;
          0:t:16:>=0;<=0;c=0;r=0;
          0:t:21:>#420;<#1344;c#0;r#0;
          0:t:22:>#1165;<#1741;c#0;r#0;
          [...]
          0:t:24:>#20839;<#14882;c#0;r#1;
          0:t:24:>#20839;<#14882;c#3;r#1;
          0:t:24:>#20839;<#14882;c#4;r#2;
          0:t:24:>#20839;<#14882;c#6;r#2;
          0:t:24:>#20863;<#14930;c#8;r#2;
          0:t:8:<;>;c;r;
          0:p:36:successful exchange with mtn://code.monotone.ca/monotone
          0:l:1:0

    *Output format:*
          Output consists of sent and received revisions, certs, and
          keys in the main stdio channel, progress messages, and ticker
          data for bytes, revisions, certs and keys.

          For non-dry-run, all stanzas are optional; they are only
          output if the data they describe is transferred.

          A partial order is imposed, that the parser can use in
          deciding how to store the data. First all certs associated
          with revisions that are not transferred in this sync are
          output, then revisions with associated certs, then keys. All
          received data is output before all sent data.

          For each cert not associated with a transmitted revision,
          there is a stanza giving the cert name, value, key, and
          revision.

          For each revision, there is a stanza containing the revision
          id, followed by a stanza containing the cert name, value,
          key, and revision id for each cert associated with the
          revision.

          For each key, there is one stanza containing one line giving
          the key id.

          If run outside of `automate stdio', the progress and ticker
          output of these commands is equal to the normal netsync
          command progress and ticker output.

          If these commands are run over stdio, the stdio ticker format
          is used (for a description of this format, see `*note mtn
          automate stdio::').

          The following ticker types are printed out during the
          refinement phase:

             * `c': The number of certs found for an upcoming
               synchronization

             * `k': The number of keys found for an upcoming
               synchronization

             * `r': The number of revisions found for an upcoming
               synchronization

          After refinement the actual synchronization between the two
          nodes start. The ticker stanzas in this phase are the
          following:

             * `>': The number of incoming bytes

             * `<': The number of outgoing bytes

             * `c': The number of incoming certs  (only pull and sync)

             * `C': The number of outgoing certs  (only push and sync)

             * `r': The number of incoming revisions  (only pull and
               sync)

             * `R': The number of outgoing revisions  (only push and
               sync)

          For dry-run, one stanza is output, with optional lines giving
          the revision, cert, and key counts for send and receive.
          Under some circumstances, the number of keys that would be
          received is only an estimate; in that case, the symbol
          `estimate' is output. For send, the branch names of sent
          revisions are also output. Note that in the branch list,
          revisions that have multiple branch certs are listed twice,
          so the sum of the revision counts in the branch list may be
          greater than the number of revisions transferred.

    *Error conditions:*
          If a netsync error occurs, the command outputs an error and
          exits with status 1.


`mtn automate put_file [BASE-ID] CONTENTS'

    *Arguments:*
          The optional BASE-ID specifies a file-id on which the
          contents are based. This is used for delta encoding. CONTENTS
          are the contents of the new file.

          If BASE-ID is not given, the file is a new file, and no delta
          is stored.

    *Added in:*
          4.1

    *Purpose:*
          Preparation of a workspace-less commit.  See `*note mtn
          automate put_revision::'.

    *Sample output:*
          70a0f283898a18815a83df37c902e5f1492e9aa2

    *Output format:*
          The sha1 sum of the contents, hex encoded.

    *Error conditions:*
          If the optional base id is unknown prints an error message to
          stderr and exits with status 1.


`mtn automate put_public_key KEY-PACKET-DATA'

    *Arguments:*
          A data packet, KEY-PACKET-DATA, as produced by `*note mtn
          automate get_public_key::'.

    *Changes:*
          13.0 - initial

    *Purpose:*
          Store public keys into the database.

          Note that this duplicates part of `*note mtn automate
          read_packets::'; the intent is to deprecate `automate
          read_packets', and only keep facilities for key packets.

    *Output format:*
          No output.

    *Error conditions:*
          An error will be produced if the argument is not a valid key
          packet.


`mtn automate put_revision REVISION-DATA'

    *Arguments:*
          REVISION-DATA is the new revision.

    *Added in:*
          4.1

    *Purpose:*
          Workspace-less commit.

          Note that the new_manifest entry is ignored - `put_revision'
          will ignore whatever you put here and calculate the correct
          manifest id itself.  (However, for now, you must put 40 hex
          digits here - it's just that which particular digits you put
          are entirely irrelevant.  All zeros is a good choice.)
          Monotone will also canonicalize your whitespace
          automatically.  You do not need to worry about getting just
          the right amount of indentation in front of each line.
          However, everything else about your revision must be valid.

    *Sample argument:*
               format_version "1"

               new_manifest [0000000000000000000000000000000000000004]

               old_revision []

               add_dir ""

               add_file "foo"
               content [5bf1fd927dfb8679496a2e6cf00cbe50c1c87145]

    *Sample output:*
          4c2c1d846fa561601254200918fba1fd71e6795d

    *Output format:*
          The new revision id, hex encoded.

    *Error conditions:*
          If the changeset is invalid prints an error message to stderr
          and exits with status 1. May abort on invalid formats.  If
          the revision is already present in the database, prints a
          message to stderr noting this fact, but otherwise works as
          normal.


`mtn automate read_packets PACKET-DATA'

    *Arguments:*
          A data packet, PACKET-DATA, as produced by `*note mtn
          pubkey::'.

    *Added in:*
          9.0

    *Purpose:*
          Store public keys (and incidentally anything else that can be
          represented as a packet) into the database.

    *Output format:*
          No output.

    *Error conditions:*
          An error will be produced if the argument is not a valid
          packet.


`mtn automate remote [--remote-stdio-host=HOST] [--[no-]set-default] COMMAND ARGS-AND-OPTS'

    *Arguments*
          A command and its arguments, to execute on the remote server
          specified by the `--remote-stdio-host' option (defaults to
          server stored in the database). If options are to be passed
          to the command, they must be preceded by `--' to prevent them
          from being interpreted as local options.

          Remote options *must* be given as a single token, ie
          `--branch=foo' or `-bfoo'. This is because the local and
          remote monotones may not understand exactly the same options
          (so the local monotone cannot know if an option given as
          `--branch' or `-b' should be followed by an argument), and
          because the server sees this as an `automate remote_stdio'
          connection (so it expects the options to already be parsed).

    *Added in*
          12.0

    *Purpose*
          Permit a single `automate' command to be run against a
          database that is being used to serve netsync connections,
          without having its input and output encoded as by `automate
          stdio'.

    *Input/Output Format*
          This command does not accept input.

          The output will be whatever output the remote command
          generates.

          Remote diagnostic messages are written to standard error,
          prefixed either with `mtn: remote error:', `mtn: remote
          warning:' or `mtn: remote message:' to make them
          distinguishable from local diagnostics. Tickers are not
          supported over this interface. If you need remote ticker
          support, see `*note mtn automate remote_stdio::'.

    *Error Conditions*
          If the remote command returns a nonzero error code, will exit
          with code 1 and print "received remote error code N" to
          standard error, with "N" being the remote error code.

    *Notes*
          If no database is specified, a `:memory:' database is used.

          On the server side the `get_remote_automate_permitted' hook
          has to be configured to include every command which should be
          executable over this interface.

          Keyboard interaction is disabled on the server, just as if
          `--non-interactive' would have been specified on server
          startup.  Actions which require operations on
          password-encrypted private keys will therefor fail unless a
          *note get_passphrase:: hook is set up remotely.


`mtn automate remote_stdio [HOSTNAME]'

    *Arguments*
          HOSTNAME is the host (and optionally port) of the monotone
          server process to connect to. If not given, the default
          server is used.

    *Added in*
          12.0

    *Purpose*
          Permit `automate' commands to be run against a database that
          is being used to serve netsync connections.

    *Input/Output format*
          This command takes input and produces output in exactly the
          same format as `automate stdio'. Note that the commands run
          with `automate remote_stdio' may conform to a different
          INTERFACE_VERSION, because they are handled by a remote
          instance of monotone.

          There will be some extra chatter on stderr unless `--quiet'
          is given.

    *Error Conditions*
          If left idle for too long or there are network problems, the
          connection to the server may be dropped. This will not be
          detected while monotone is waiting for input. Instead, when a
          complete command has been entered and monotone tries to send
          it to the remote server it will print a message to stderr and
          exit with code 1.

    *Notes*
          If no database is specified, a `:memory:' database is used.

          On the server side the `get_remote_automate_permitted' hook
          has to be configured to include every command which should be
          executable over this interface.

          For both, the client and the server, keyboard interaction is
          disabled, just as if `--non-interactive' is specified.
          Actions which require operations on password-encrypted
          private keys will therefor fail unless the *note
          get_passphrase:: hook is set up locally and / or remotely.


`mtn automate roots'

    *Arguments:*
          None.

    *Added in:*
          4.3

    *Purpose:*
          Prints the roots of the revision graph, i.e. all revisions
          that have no parents.

    *Sample output:*
          276264b0b3f1e70fc1835a700e6e61bdbe4c3f2f

    *Output format:*
          Zero or more lines, each a root of the revision graph.  Each
          line consists of a revision ID, in hexadecimal, followed by a
          newline.  The lines are printed in alphabetically sorted
          order.

    *Error conditions:*
          None.


`mtn automate select SELECTOR'

    *Arguments:*
          One selector (or combined selector).

    *Added in:*
          0.2

    *Purpose:*
          Print all revisions that match the given selector.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          Zero or more lines, each giving the ID of one revision that
          matches the given selector.  Each line consists of a revision
          ID, in hexadecimal, followed by a newline.  Revision ids are
          printed in alphabetically sorted order.

    *Error conditions:*
          None.


`mtn automate set_attribute PATH KEY VALUE'

    *Arguments:*
          A path, an attribute key and an attribute value.

    *Added in:*
          5.0

    *Purpose:*
          Edits the current workspace revision and inserts the given
          attribute key and value for the specified path. Note that
          this change is not committed and therefor behaves exactly
          like `mtn attr set KEY VALUE'.

    *Output format:*
          This command does not print out anything if successful.

    *Error conditions:*
          If the path specified is unknown in the new workspace
          revision, prints an error message to stderr and exits with
          status 1.


`mtn automate set_db_variable DOMAIN NAME VALUE'

    *Arguments:*
          The DOMAIN and NAME specify the database variable which is
          changed to VALUE.

    *Changes:*
             * 7.0 - renamed to 'set_db_variable'

             * 4.1 - added as 'db_set'

    *Purpose:*
          Change a database variable; see *note Vars::.

    *Sample usage:*
          mtn automate set_db_variable database default-server off.net

    *Output format:*
          No output.

    *Error conditions:*
          None.


`mtn automate show_conflicts [-BRANCH BRANCH] [LEFT_REV RIGHT_REV]'

    *Arguments:*
          Optional left and right revision ids.

          If no revs are given, they default to the first two heads
          that would be chosen by the `merge' command for the current
          branch. If no workspace is present, the branch may be given
          by the -BRANCH option.

    *Changes:*
             * 11.0 - Add resolution for orphaned node conflicts.
               Deleted `resolved_user' conflict resolution; use
               `resolved_*_left' for single file conflicts. Add
               `resolved_keep_left, resolved_keep_right' resolutions.

             * 9.0 - Added default resolution for file content
               conflicts, user resolutions for others.
               `directory_loop_created' changed to `directory_loop'.

             * 8.0 - initial

    *Purpose:*
          Show all conflicts between two revisions.

          This is intended to be used before a `merge'; an external tool
          can guide the user thru resolving each conflict in turn, then
          do the merge.

          The same file format is output by the `conflicts store'
          command, which also allows specifying user conflict
          resolutions. The file syntax for the resolutions is given
          here, so an external tool can set them directly.

          For more information on conflicts, see *note Merge
          Conflicts::.

          Note that this cannot be used to show conflicts that would
          occur in an `update', since in that case one revision is the
          workspace.

    *Sample output:*
          The output starts by listing the revisions and their common
          ancestor:     left [532ab5011ea9e64aa212d4ea52363b1b8133d5ba]
             right [b94a03a922c2c281a88d8988db64e76a32edb6a1]
          ancestor [ead03530f5fefe50c9010157c42c0ebe18086559]

          If there are no conflicts, the ancestor revision is not
          output, and no conflict stanzas are output.

          Attribute changed in both branches, or dropped in one:         conflict attribute
                 node_type "file"
                 attr_name "attr1"
             ancestor_name "foo"
          ancestor_file_id [bab2022ff2ed13501a8a83bcc6bd53f5042141be]
                 left_name "foo"
              left_file_id [bab2022ff2ed13501a8a83bcc6bd53f5042141be]
           left_attr_value "valueX"
                right_name "foo"
             right_file_id [bab2022ff2ed13501a8a83bcc6bd53f5042141be]
          right_attr_value "valueZ"

                  conflict attribute
                 node_type "file"
                 attr_name "attr2"
             ancestor_name "foo"
          ancestor_file_id [bab2022ff2ed13501a8a83bcc6bd53f5042141be]
                 left_name "foo"
              left_file_id [bab2022ff2ed13501a8a83bcc6bd53f5042141be]
           left_attr_value "valueY"
                right_name "foo"
             right_file_id [bab2022ff2ed13501a8a83bcc6bd53f5042141be]
          right_attr_state "dropped"

          Missing root directory:      conflict missing_root
              left_type "pivoted root"
          ancestor_name "foo"
             right_type "deleted directory"
          ancestor_name "foo"

          Directory deleted and/or renamed:      conflict orphaned_directory
             right_type "deleted directory"
          ancestor_name ""
              left_type "renamed directory"
          ancestor_name ""
              left_name "bar"

               conflict orphaned_file
             right_type "deleted directory"
          ancestor_name "foo"
              left_type "added file"
              left_name "foo/baz"
           left_file_id [f5122a7f896cb2dd7ecaa84be89c94ab09c15101]

                  conflict orphaned_file
                right_type "deleted directory"
             ancestor_name "foo"
                 left_type "renamed file"
             ancestor_name "bar"
          ancestor_file_id [ac4c6d06436632e017bb7d3ea241734e8899f8ce]
                 left_name "foo/baz"
              left_file_id [ac4c6d06436632e017bb7d3ea241734e8899f8ce]

               conflict multiple_names
              left_type "renamed directory"
          ancestor_name ""
              left_name "aaa"
             right_type "renamed directory"
          ancestor_name ""
             right_name "bbb"

               conflict duplicate_name
              left_type "renamed directory"
          ancestor_name "foo"
              left_name ""
             right_type "renamed directory"
          ancestor_name "bar"
             right_name ""

               conflict multiple_names
              left_type "renamed directory"
          ancestor_name "foo"
              left_name "a/foo"
             right_type "renamed directory"
          ancestor_name "foo"
             right_name "b/foo"

          Directory loop created:      conflict directory_loop
              left_type "renamed directory"
          ancestor_name "foo"
              left_name "bar/foo"
             right_type "renamed directory"
          ancestor_name "bar"
             right_name "foo/bar"

          File content changed (this may be resolvable by the internal
          line merger), file also renamed:          conflict content
                  node_type "file"
              ancestor_name "bar"
           ancestor_file_id [f0ef49fe92167fe2a086588019ffcff7ea561786]
                  left_name "bar"
               left_file_id [08cd878106a93ce2ef036a32499c1432adb3ee0d]
                 right_name "bar"
              right_file_id [0cf419dd93d38b2daaaf1f5e0f3ec647745b9690]
          resolved_internal

                  conflict content
                 node_type "file"
             ancestor_name "foo"
          ancestor_file_id [50bf338804db2685a575124c8c8371d06b65c523]
                 left_name "bar"
              left_file_id [f1bb6fff2ad16d67143d89fc374ede7abec5d437]
                right_name "baz"
             right_file_id [b966b2d35b99e456cb0c55e4573ef0b1b155b4a9]
           `resolved_internal' is a conflict resolution. If the file
          contents in the two revs can be successfully merged by the
          internal line merger, `resolved_internal' is output.

          File added and/or renamed:      conflict duplicate_name
              left_type "added file"
              left_name "bar"
           left_file_id [ba4637112ee3e55a6106d647d6c4e04a6643f8eb]
             right_type "added file"
             right_name "bar"
          right_file_id [fe6d523f607e2f2fc0f0defad3bda0351a95a337]

                  conflict duplicate_name
                 left_type "renamed file"
             ancestor_name "foo"
          ancestor_file_id [c6864a8456855c48afe83488a47501fe8b94bd57]
                 left_name "bar"
              left_file_id [c6864a8456855c48afe83488a47501fe8b94bd57]
                right_type "added file"
                right_name "bar"
             right_file_id [c809d71002ec57a2f1d10221f05993012a491436]

                  conflict duplicate_name
                 left_type "renamed file"
             ancestor_name "foo"
          ancestor_file_id [918f3642b57a5e2dd13ee874e3dc2518a53ab4b4]
                 left_name "abc"
              left_file_id [918f3642b57a5e2dd13ee874e3dc2518a53ab4b4]
                right_type "renamed file"
             ancestor_name "bar"
          ancestor_file_id [bdf46a521d5f1dd54c31dda15e99ff6b0c80394a]
                right_name "abc"
             right_file_id [bdf46a521d5f1dd54c31dda15e99ff6b0c80394a]

          File renamed to different names:         conflict multiple_names
                 left_type "renamed file"
             ancestor_name "foo"
          ancestor_file_id [e80910e54d0bdea1b6d295ada320b87aaf9fdc23]
                 left_name "bar"
              left_file_id [e80910e54d0bdea1b6d295ada320b87aaf9fdc23]
                right_type "renamed file"
             ancestor_name "foo"
          ancestor_file_id [e80910e54d0bdea1b6d295ada320b87aaf9fdc23]
                right_name "baz"
             right_file_id [e80910e54d0bdea1b6d295ada320b87aaf9fdc23]

          Invalid file name (`_MTN' in root directory):      conflict invalid_name
              left_type "pivoted root"
          ancestor_name "foo"
             right_type "added directory"
             right_name "foo/_MTN"

                  conflict invalid_name
                 left_type "pivoted root"
             ancestor_name "foo"
                right_type "renamed file"
             ancestor_name "bad/_MTN"
          ancestor_file_id [629d9e5d254241abf4b46f108fb53189e314e41d]
                right_name "foo/_MTN"
             right_file_id [629d9e5d254241abf4b46f108fb53189e314e41d]

          Revisions that don't share a common ancestor:     left [161e426c3b0c3f98d0be225f69d6f893ce8e0442]
             right [0e3260f51acd1e98c40666557eb6c0eefeae5f02]
          ancestor []

          conflict missing_root

            conflict duplicate_name
           left_type "added directory"
           left_name ""
          right_type "added directory"
          right_name ""

          All possible conflict resolutions:    resolved_drop_left
            resolved_drop_right
             resolved_keep_left
            resolved_keep_right
              resolved_internal
           resolved_rename_left file
          resolved_rename_right file
             resolved_user_left file
            resolved_user_right file
           For single file conflicts, the `resolved_*_left' resolution
          name is used.

          *Note Conflicts::, for more information on conflict
          resolutions.

    *Output format:*
          First the revision ids of the left and right revisions, and
          their common ancestor, are printed in one basic_io stanza.

          Then each conflict is listed in a basic_io stanza. Stanzas are
          separated by blank lines.

          Each conflict stanza starts with a `conflict' line, and
          contains up to eleven lines. The order of the lines is not
          important, and may change in future revisions, except that
          the first line will always be `conflict'.

          When the conflicts involve files, the file ids are output, so
          the file contents can be retrieved efficiently via `automate
          get_file', to aid in conflict resolution.

          Only the `resolved_internal' conflict resolution is output by
          this command; the other conflict resolutions are inserted in a
          conflicts file by `conflicts resolve_first' or an external
          tool, and read by `merge'.

    *Error conditions:*
          If the revision IDs are given, but either is unknown or
          invalid, prints an error message to stderr and exits with
          status 1.


`mtn automate stdio'

    *Arguments:*
          none

    *Changes:*
             * 12.0 - Introduced out of band streams ('e', 'p', 't',
               'w'); the main output     of a command now only happens
               in the 'm' stream; the 'l' stream now marks     the end
               of all streams of a command; introduced the concept of
               "headers"     which are output before the first command
               is issued; specific error codes     to distinguish
               command from interface errors have also been introduced.

             * 3.1 - Added the 'o' item to the recognized input. This
               change should not break anything.

             * 1.0 - Initial version.

    *Purpose:*
          Allow multiple automate commands to be run from one instance
          of monotone.

    *Sample input:*
          l6:leavese
          l7:parents40:0e3171212f34839c2e3263e7282cdeea22fc5378e
          o3:key11:foo@bar.come l4:cert40:0e3171212f34839c2e3263e7282cdeea22fc53783:foo3:bare

    *Input format:*
          [ 'o' <string> <string> [ <string> <string> [ ... ] ] 'e' ]
          'l' <string> [ <string> [ ... ] ] 'e'

          The input is a series of commands and options. The command
          name plus arguments are provided as 'l' <string> [<string>
          ...] 'e', where <string> = <size> colon <data> . This may
          optionally be preceded by a set of key=value pairs (command
          options) as 'o' <string> <string> [<string> <string> ...]
          'e', where strings come in pairs, key followed by value. For
          flag options that don't take values, specify the second
          string as zero length; `0:'. The option names do _not_
          include the leading `--'.

          The space between the ending 'e' of one group of strings and
          the beginning 'l' or 'o' of the next is reserved. Any
          characters other than whitespace will cause an error.

    *Sample output:*
          format-version: 2

          0:m:41:7706a422ccad41621c958affa999b1a1dd644e79
          0:l:1:0
          ...
          1:e:38:misuse: key 'test@test' already exists
          1:l:1:2
          ...
          2:w:39:skipping file '\' with unsupported name
          2:m:144:    path ""
          old_type "directory"
          new_type "directory"
           fs_type "directory"
             birth [276264b0b3f1e70fc1835a700e6e61bdbe4c3f2f]
            status "known"
          ...
          3:t:34:c:certificates;k:keys;r:revisions;
          3:t:12:c=0;k=0;r=0;
          3:t:13:c#0;k#0;r#64;
          3:t:14:c#0;k#0;r#128;
          3:t:6:c;k;r;
          ...

    *Output format:*
          Right after a stdio session has been set up, header
          information is issued; to date the only header defined is
          `format-version', which denotes the version of the stdio
          format used throughout the session. The original format had
          no such version output, so our numbering starts with "2" here.

          Headers are separated from each other by single newline
          character `'\n'' and the last is separated from the following
          output by a pair of newline characters.

          After a command has been issued, one or more packets are
          returned for it.  A packet looks like:

          <command number>:<stream>:<size>:<output>

          `<command number>' is a decimal number specifying which
          command this output is from. It is 0 for the first command,
          and increases by one each time.

          `<stream>' is an identifier for which output stream this
          packet represents, allowing multiple streams to be
          multiplexed over the channel.  The following streams are
          presently defined; more streams may be added later.

             *  `m': this stream represents the normal ("main") stdout
               automate output of  the command, formatted as described
               in the description for that command.

             *  `e': this stream represents any (unstructured) error
               message data.

               Internally, this maps to calls to the `E()' print macros
               that would  normally be written by the command to the
               program's stderr stream, if the  automate sub-command
               had been called directly rather than via "'stdio"'.

             *  `w': this stream represents any (unstructured) warning
               message data.

               Internally, this maps to calls to the `W()' print macro
               that would  normally be written by the command to the
               program's stderr stream, if the  automate sub-command
               had been called directly rather than via "'stdio"'.

             *  `p': this stream represents any (unstructured) progress
               message data.

               Internally, this maps to calls to the `P()' print macro
               that would  normally be written by the command to the
               program's stderr stream, if the  automate sub-command
               had been called directly rather than via "'stdio"'.

             *  `t': this stream represents ticker updates, which may
               be used  by a user interface to display the progress of
               a command.

               The output for this channel can be described as follows:

                  *  `<output>       ::= <definition><payload><end>'

                  *  `<definition>   ::= <shortname> ':' <longname>
                    <eol>'

                  *  `<payload>      ::= <total_count><advance>+'

                  *  `<end>          ::= <shortname> <eol>'

                  *  `<total_count>  ::= <shortname> '=' <count> <eol>'

                  *  `<advance>      ::= <shortname> '#' <count> <eol>'

                  *  `<shortname>    ::= "\w+"'

                  *  `<longname>     ::= "[^;]+"'

                  *  `<count>        ::= ['0'-'9']+'

                  *  `<eol>          ::= ';''

               The definition tells the implementor the short name and
               long name of any upcoming ticker event. The names and
               meanings are command-specific and are therefore
               explained in the sections for the particular commands
               which support ticker output.

               The `total_count' might be 0 right at the start and can
               later be changed to a different number if the command
               later on knows a more exact value. If this is the case,
               this stanza is output again with this new value. A
               constant `total_count' of 0 means that the command may
               continue to run for a undefined amount of time until the
               end stanza appears.

               The advance tells the implementor how much work has been
               done so far.

               Finally, the end stanza is printed just before the
               ticker ends (i.e. the work has been done).

               All counts output absolute, raw values; no modulation
               takes place. It is usually the case that definition,
               `total_count', advance and end are output in separate
               stanzas. It is also possible that two or more parallel
               tickers output their stanzas at the same time, in this
               case it's ensured that the output does not get
               intermixed; first all definitions are output, afterwards
               all total_counts, and so on.

               _Note:_ The ticker format used for stdio is fixed and
               cannot be selected explicitely via the global `--ticker'
               option. However, if you run an automate command outside
               of stdio you can set a different ticker type, f.e.
               COUNT, DOT or NONE.

             *  `l': this stream marks the termination of a command and
               all of  its streams and carries the return code of the
               command in the payload.

               A return code "0" stands for success, "1" for an error
               which occurred within  the stdio interface (f.e. syntax
               errors or missing privileges) before the  command is run
               and finally "2" for any other command-specific error.

          `<size>' is the number of bytes in the output.

          `<output>' is a piece of the output of the command.

    *Error conditions:*
          Errors in the commands run through this interface do not
          affect the exit status of this command. Instead, if a badly
          formatted or invalid command is received, or a command is
          given with invalid arguments or options, an error message to
          the error stream is printed and and the particular
          sub-command exits with return code "1". Other
          command-specific errors are returned as code "2".

          Trying to run the `automate stdio' or `automate remote_stdio'
          sub-commands will exit the particular command with return
          code "1".

    *Notes:*
          Keyboard interaction is disabled, just as if
          `--non-interactive' is specified. Actions which require
          operations on password-encrypted private keys will therefore
          fail unless the `*note get_passphrase::' hook is set up
          locally.

          Workspace options are read before executing each command.

    *Multiple streams*
          The multiple stream encoding allows the output of errors and
          warnings to be associated with the command that generated
          them, allows the communication path to always stay in sync,
          and offers the opportunity to add other stream types for
          other useful purposes in the future as needs arise.


`mtn automate sync'
     See `*note mtn automate pull::'

`mtn automate tags [BRANCH_PATTERN]'

    *Arguments:*
          A branch pattern (defaults to all).

    *Changes:*
             * 11.0 - SIGNER now prints the hash of the signing key, no
               longer the name.          Also, the FORMAT_VERSION
               stanza has been removed in favour of the         global
               INTERFACE_VERSION.

             * 2.2 - added

    *Purpose:*
          If a branch pattern is given, prints all tags that are
          attached to revisions on branches matched by the pattern;
          otherwise prints all tags of the revision graph.

          If a branch name is ignored by means of the Lua hook `*note
          ignore_branch::', it is neither printed, nor can it be
          matched by a pattern.

    *Sample output:*
               tag "monotree-0.1"
          revision [8a121346ce2920b6f85df68b3b620de96bd14a8d]
            signer [de84b575d5e47254393eba49dce9dc4db98ed42d]
          branches "net.venge.monotone.contrib" "net.venge.monotone.contrib.monotree"

               tag "monotree-0.2"
          revision [5d288b39b49613b0d9dca8ece6b9a42c3773f35b]
            signer [de84b575d5e47254393eba49dce9dc4db98ed42d]
          branches "net.venge.monotone.contrib.monotree"

               tag "monotree-0.3"
          revision [35cff8e8ba14155f5f7ddf7965073f514fd60f61]
            signer [de84b575d5e47254393eba49dce9dc4db98ed42d]
          branches "net.venge.monotone.contrib.monotree"

               tag "monotree-0.4"
          revision [f1afc520474f83c58262896ede027ef77226046e]
            signer [de84b575d5e47254393eba49dce9dc4db98ed42d]
          branches "net.venge.monotone.contrib.monotree"

    *Output format:*
          There is one basic_io stanza for each tag.

          Each stanza has exactly the following four entries:

         `'tag''
               the value of the tag cert, i.e. the name of the tag

         `'revision''
               the hexadecimal id of the revision the tag is attached to

         `'signer''
               the hexadecimal value of the key used to sign the tag
               cert

         `'branches''
               a (possibly empty) list of all branches the tagged
               revision is on

          Stanzas are printed in arbitrary order.

    *Error conditions:*
          A run-time exception occurs if an illegal branch pattern is
          specified.


`mtn automate toposort [REV...]'

    *Arguments:*
          One or more revision IDs.

    *Added in:*
          0.1

    *Purpose:*
          Prints all arguments, topologically sorted.  I.e., if REV1 is
          an ancestor of REV2, then REV1 will appear before REV2 in the
          output; if REV2 is an ancestor of REV1, then REV2 will appear
          before REV1 in the output; and if neither is an ancestor of
          the other, then they may appear in either order.

          If there are no arguments, prints nothing.

    *Sample output:*
          28ce076c69eadb9b1ca7bdf9d40ce95fe2f29b61
          75156724e0e2e3245838f356ec373c50fa469f1f

    *Output format:*
          A list of revision IDs, in hexadecimal, each followed by a
          newline.

    *Error conditions:*
          If any of the revisions do not exist, prints nothing to
          stdout, prints an error message to stderr, and exits with
          status 1.


`mtn automate update'

    *Arguments:*
          Same as `*note mtn update::'.

    *Added in:*
          12.1

    *Purpose:*
          Update the current workspace to the latest or given revision;
          see `*note mtn update::'.

    *Sample output:*
          Nothing on the main stream. The progress stream gives
          messages of the form: mtn: updating along branch 'mms.work_stephe'
          mtn: selected update target 233afb8c4832bf33d5f5734225164de5f5a6278c
          mtn: [left]  4a368a6b217c40b2ff3b12bb7cfa00987e0f191c
          mtn: [right] 233afb8c4832bf33d5f5734225164de5f5a6278c
          mtn: renaming build/windows_common.make to build/utf_common.make
          mtn: adding build/x86_gnu_linux_release

    *Output format:*
          Free form, prefixed by "mtn:".

    *Error conditions:*
          see `*note mtn update::'.



