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:
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.
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:
Any file name beginning with .mtn-
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”.
The following control files are currently used. More control files may be added in the future, but they will follow the patterns given above.
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. See Regexps, for the syntax of these regular expressions.
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.
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.
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.
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.
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.
If this file exists, monotone considers the directory to be in Inodeprints mode, and uses this file to cache the inodeprints.
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.
Contains the current state of an ongoing bisection. See Bisecting for more information.
Remembers the update / previous base revision of the workspace when
u: selector is used. See Selectors for more information.
The default file which is used by monotone to read and write merge conflicts for conflict resolution. See Conflicts for more information.
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.