Version 2 (modified by 17 years ago) (diff) | ,
---|
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
Running
mtn refresh_inodeprints
Will create a inode cache of your workspace. This will dramatically reduce the runtime of mtn status, commit, etc. Technically this method is less secure then the default behavior. Please read this 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.