Monotone Best Practices

The purpose of this page is to create a set of best practices for the use of pidgin monotone. When deemed worthy, it will be merged into UsingPidginMonotone.

Speedups

mtn refresh_inodeprints

Will create a inode cache of your current workspace. This will dramatically reduce the runtime of mtn status, commit, etc. Technically this method is less secure then the default behavior. Please read the ​official docs for more information.

Branching

Branching has always been a confusing topic and has always had lots of confusing documentation. In an attempt to avoid that, the following subtopics are meant to make understand branches easier as well as explain how they work in monotone.

Branch names

Branch names should be descriptive and follow a hierarchy. For example, for the 2007 Summer of Code projects, we are using im.pidgin.soc.2007.<project name>. Using a setup like this, it is easy to tell at a glance of mtn ls branches that im.pidgin.soc.2007.monoloader is a 2007 Summer of Code project branch.

Creating Branches

From a Working Copy

To create a branch from your working copy use:

mtn ci -b <new_branch>

This will check it the new branch into your local database and change the current branch of your working copy to <new_branch>. You will of course still need to push your branch out to the "central" server on pidgin.im.

From Scratch

Someone fill this in, I haven't done it yet.

Pulling New Branches

If you did not do an initial pull with mtn pull pidgin.im im.pidgin.* it is possible that you will not automagically pull new branches. If you have noticed a lack of branches in mtn ls branches you can remedy this one of two ways.

From a working copy:

mtn pull pidgin.im "im.pidgin.*"

From anywhere:

mtn -d <path to your pidgin database> pull pidgin.im "im.pidgin.*"

Note: Both of these methods have yet to be confirmed to fix the problem.