Without a --revision argument, the command outputs the contents of path as found in the current revision. This requires the command be executed from within a workspace.
With an explicit --revision argument, the command outputs
contents of path at that revision.
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 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.
Conceptually, disapproves 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 id has exactly one ancestor, since it hasn't been
worked out how to generate such a descendant in the multi-ancestor case.
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.
A commit message may be provided. 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.
A commit message may be provided. 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.
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.
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 --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.