Currently active development branches:
Contact: EmileSnyder
Staging branch for work on the annotate command. As of 2006-01-30, there is work in progress on implementing per-file-DAGs of the revision graph in the db so that you can walk just the portion of the full graph in which changes were made to a given file.
In order to try it, you must migrate your db and then run monotone db filedagify on the database of interest.
Todo: write tests for schema migration, fix kill_rev_locally to get rid of the node_revision_ancestry entries as well, figure out why new annotate is not identical to the old implementation, extend to handle all types of file changes (renames and attr changes) so it can be used to speed up restricted log too, roll filedagify into the migration?
Status: Work in Progress
Contact: ChristofPetig, ThomasKeller
Adds support for multiple streams into monotone stdio which includes separate streams for informational messages (infos, warnings, errors, ...) as well as tickers. To actually test tickers automate pull is already included here.
Status: Documentation is in place, Needs Tests
Contact: StephenLeake
The branch name is misleading; the automate_show_conflicts branch is now about implementing file sutures.
The original work on conflict resolution moved to nvm.resolve_conflicts, which has landed.
Strategy: Support file sutures, to provide true resolution of duplicate name conflicts by recording both parents.
Status: Stalled Abandoned August 2008; way too much work for very little gain.
Contact: ThomasKeller
Implements the netsync commands push, pull and sync in automate, especially for use within automate stdio. Enforces and checks the usage of a running ssh-agent instance to avoid password prompting.
Status: Documentation is in place, Needs Tests
Contact: ThomasKeller
Tries to implement a stdio ticker so automate clients can actually monitor the progress of a netsync operation.
Status: Unusable, should probably be suspended and/or redone from scratch (and maybe rethought even when / if nvm.nuskool gets ready?)
Superseded by nvm.automate out of band ?
Contact: MarkusWanner or TimothyBrownawell
This is the staging branch for Botan, i.e. where we manually propagate new upstream Botan versions to, before landing on mainline. See also botan/README.botan-monotone.
Status: Botan version 1.7.4 landed on mainline.
[[!comment there is no local copy of Botan anymore; is this branch needed?]] Contact: MarkusWanner
Adds a --with-system-botan configure switch, to allow using the system provided copy of botan. Especially note, that the system provided library most probably features the assembler optimizations for SHA1, where as the bundled botan currently does not.
Status: Stalled
Contact: RichardLevitte
This branch implements the command mtn branch and consequently,
removes the -b option from mtn commit.
mtn branch fiddles with _MTN/options, adding a new option called
newbranch, which mtn commit picks up at commit time.
Info from the old wiki:
Contact: ThomasKeller
An attempt to remove the --branch option from "mtn commit" and replace the functionality by a new "mtn branch" command which explicitely sets the branch stanza in _MTN/options. This basically works, but is not thoroughly thought through for now, basically because we loose the old branch information after "mtn branch", so subsequent commands like "mtn update" which still rely on the old_revision and the recorded branch name fail badly unless the workspace is committed again. So, what still needs to be done is
- if mtn branch is triggered on an unmodified workspace, mtn commit should succeed and just add the new branch cert to old_revision
- if the branch is switched, the new branch name should be recorded as "new_branch" while keeping "branch" untouched unless commit happens, so "mtn update" and friends work properly
- mtn revert should remove any "new_branch" stanza from _MTN/options
- eventually "mtn branch" should be renamed to "mtn switch" and get some more functionality (i.e. if switched to a named, existing branch, update the workspace to the head of this branch)
Status: Stalled, decide what to do with all that.
Contact: MarkusWanner
Features a graph-based cvs import algorithm, loosely based on the concepts of cvs2svn 2.0. For more details, see CvsImport
Status: Work in Progress Still close to completion 
(outdated)
Contact: ChristofPetig
Adds two-way syncing with (remote) CVS servers
Christof (and his collegues) use this branch for their daily work against their CVS servers, so it's definitely usable. Documentation is available.
Open issues: the data structure (map) has difficulties and is inefficient for large (>1000 changesets) repositories; propagates gather too much changelog info; most problems arise when $Id$ tags get expanded differently; not yet reindented with GNU style.
See also Hints.
Status: Work in Progress
[[!comment not clear if discussion is current]] Contact: ChristofPetig
A re-implementation of the cvssync architecture to be more modular, including a separate external process that interacts as a cvs client.
What is done:
- mtn_cvs pull, push and takeover work with side branches and all sorts of strange setups (see tests) and are now attribute based
What needs to be done:
- implement changed files
- implement sane branch connecting (or share with cvs_import)
- share the changeset-ification logic with cvs_import (I use the most simple approach for now)
- write documentation
- write migration helpers for the old branch
What can be put into mainline:
- the piece_table abstraction can be shared with cvs_import (once I had committed the change)
- all automate extensions (the synchronization commands are about to change again to use attributes, so they might wait)
- the mtn_automate class (C++ wrapper library to access monotone via automate)
- the mtn_cvs directory infrastucture can be put into mainline but can wait as well until it's finished
Status: Work in Progress
Contact: MatthewNicholson
This branch adds a monotone-server debian package and also includes some tweaks to the existing package like installing the bash completion files. This package handles creation and management of a monotone database and key pair and also includes scripts for stopping and starting the server. The package will also attempt to do db migrate and similar operations if necessary during upgrades.
Status: Landed on mainline.
Contact: MarkusWanner
A branch for trying out things from DatabaseCompaction. It has been used for turning hex encoded hashes ones into binary data in the database. That change has landed on mainline on 31.03.2008.
Status: landed on mainline
Contact: ZackWeinberg
Removed the app_state from lots of places, instead we only pass down
the required objects, which were formerly held in the
app_state. These include: the lua interpreter, the database, the key
store and the options.
Status: landed on mainline
Contact: NathanielSmith
Some experimental UI and doc tweaks, in attempt to make things more streamlined and friendly to new users.
Current changes: setup is renamed to new_project. pull and
setup have --new-db switches, avoiding the need to db init in
almost all cases. Tempted to rename genkey too...
Todo: get feedback; update docs accordingly; write tests
Status: Work in Progress
Contact: ThomasKeller
An attempt to bring warnings and informal messages properly encoded into automate stdio.
Status: Stalled Doesn't compile, not even alpha state. Hope to find some time for this on the next summit.
(renamed from ?nvm.levitte.select-heads-of)
Contact: RichardLevitte
Implements a framework for MagicSelectors as well as a few simple ones, like H: and branch point/last common ancestor.
Status: Tests are in place, Needs Documentation
Contact: StephenLeake
mtn sync file: and mtn sync ssh: do not work reliably on Windows MinGW.
The core problem is that Win32 does not support select on pipes.
This branch attempts to replace Win32 pipes by sockets.
It fails, because ssh doesn't create sockets when it runs mtn.
See comments in netxx_pipe.hh
See nvm.experimental.win32 pipes 2 for another approach.
Status: Stalled; use Cygwin instead, where things just work.
Contact: StephenLeake
Second attempt to fix mtn sync file: and mtn sync ssh: on Windows MinGW.
See nvm.experimental.win32 pipes for another approach.
This branch attempts to fix the named pipe solution that is in the main branch.
See comments in netxx_pipe.hh
Status: Stalled no actual work beyond planning done.
Contact: ChristofPetig and MarkusWanner
Connected to nvm.partialpull.
Both branches are about partial pulls, i.e. storing only revisions newer than those of a certain horizon (including them). See PartialPull for more information and a nice illustration. Both branches introduce some form of a sentinel, which covers an inexistant or incomplete revision. The difference for n.v.m.gaps is, that these sentinels don't just cover all revisions from the covered one until the root (null revision), but to any arbitrary revision, from which we have the revision data again.
For more information, see this mailing list thread here: http://lists.gnu.org/archive/html/monotone-devel/2007-05/msg00185.html
Status: Experimental
Contact: ThomasMoschny
Implemented RevisionNumbering. The branch also serves as testbed for developing and testing applications of the heights, e.g. fast restricted log and fast annotate.
Status: Landed on mainline.
Contact: LapoLuchini
Making use of extra terminal features that may be available, such as colours (useful for diff and for asciik branch-lines).
Status: rough and Experimental
[[!comment selectors improved in 0.99; is this branch still useful?]]
Contact: LapoLuchini
Rewrite of selectors to actually be a language capable of generic operations on revision sets.
Contact: MarkusWanner, DerekScherger
The goal of the nuskool branch is to replace netsync with a faster, DAG based algorithm.
Status: Stalled
Contact: ChristofPetig
Connected to nvm.gaps.
Both branches are about partial pulls, i.e. storing only revisions newer than those of a certain horizon (including them). See PartialPull for more information and a nice illustration. Both branches introduce some form of a sentinel, which covers an inexistant or incomplete revision. The difference for n.v.m.gaps is, that these sentinels don't just cover all revisions from the covered one until the root (null revision), but to any arbitrary revision, from which we have the revision data again.
For more information, see this mailing list thread here: http://lists.gnu.org/archive/html/monotone-devel/2007-05/msg00185.html
Status: ?Experimentatal
Contact: ThomasKeller
Replaces automate content_diff by a generic automate diff command
which outputs the complete changeset (including node adds, drops,
renames and attribute changes) in an generic basic_io format. The
actual diff is included in a data stanza in unified diff format.
There hasn't yet been
an consensus if this should really be the "official" format mtn should
use to express external changesets - primarily because once this is
set into stone we certainly want an automate apply_diff command to
complement this functionality. We also still have to find a way to
express binary deltas within this new format to make it really useful
for the apply_diff use case.
Status: Stalled for quite a long time, as above
Contact: MarkusWanner
An initial attempt at importing subversion repositories into monotone. Didn't touch that for a while, as the CVS importer is still bugging me.
Status: Experimental
Contact: all Developers
Main branch containing the monotone ikiWiki.
Status: don't merge with net.venge.monotone!