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
Provide simple flow to resolve non-content conflicts.
Strategy: Add automate show_conflicts, to aid in
determining how to resolve the conflicts. Then add options to merge
to specify how to resolve the conflicts.
Status: Stalled 'automate show_conflicts' completed May 2008; merged to main. Started work on file sutures, to provide true resolution of duplicate name conflicts. Abandoned August 2008; way too much work. Branch nvm.resolve_conflicts started with simpler approach to conflict resolution.
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.
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 ?CvsSyncHints.
Status: Work in Progress
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|MagicSelectors#branchpoint]].
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
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
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 respectively
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
Contact: LapoLuchini
Rewrite of selectors to actually be a language capable of generic operations on revision sets.
Contact: RichardLevitte Created: 2006-02-28
The purpose of this branch is to add a suite of tests for usher and make it a supported program instead of just a contributed thingy.
Status: Work in Progress
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: StephenLeake
Provide simple flow to resolve non-content conflicts.
Strategy: Add conflicts store``,conflicts
resolve_*` commands, to let the user specify conflict resolutions
asynchronously from the merge process.
Status: landed
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: StephenLeake
Random small jobs.
Add --reverse option for 'diff', to specify direction for diffs involving the workspace; landed.
Fix 'conflict' to handle directories, add 'keep' resolution.
Strategy: write tests that break, fix code till they pass.
Status: Work In Progress tests passing; ready to land. Need to merge from main first.
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: DanielCarosone, all Developers
Migration of website content and MoinMoin wiki to ikiwiki.
Status: Work in Progress