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 _MTN/revision; they will be part of the next commit. See 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. However, note that the default for list unknown is --recursive, while the default for add is --no-recursive.

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.

mtn attr

Manage 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.

Several attributes are reserved for mtn use; they all start with “mtn:”:

mtn:encoding

Specify character encoding for the file.

mtn:execute

File is executable.

mtn:manual_merge

Don’t use internal or external diff or merger.

mtn:resolve_conflict

Specify drop resolution for a recurring dropped/modified conflict (dropped_modified_conflict).

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 _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 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 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 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 _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 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 _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 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. See Selectors.

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 plucking.

Merge Conflicts and 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 _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 File Attributes for more details.

Note that you cannot rename a branch. You can accomplish something similar by creating a new branch with the desired name, using the mtn approve command to add a branch name to the desired revision.

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. See Selectors.

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 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 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.

Merge Conflicts and Workspace Collisions can occur.