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

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags: ?MtnSummit/2008

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags: ?MtnSummit/2008

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 ?

Posted Fri Oct 8 01:22:08 2010 Tags:

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

[[!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

Posted Fri Oct 8 01:22:08 2010 Tags:

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

  1. if mtn branch is triggered on an unmodified workspace, mtn commit should succeed and just add the new branch cert to old_revision
  2. 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
  3. mtn revert should remove any "new_branch" stanza from _MTN/options
  4. 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.

Posted Fri Oct 8 01:22:08 2010 Tags: ?MtnSummit/2008

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 :-)

Posted Fri Oct 8 01:22:08 2010 Tags:

(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

Posted Fri Oct 8 01:22:08 2010 Tags:

[[!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

Posted Sun Dec 19 22:52:43 2010 Tags:

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

(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

Posted Fri Oct 8 01:22:08 2010 Tags: ?MtnSummit/2008

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

Contact: ?PetrBaudis

Adds two-way syncing with git repositories (unix only).

Status: I'm not quite sure. Petr? (ms) hasn't been touched for awhile, Stalled.

Posted Fri Oct 8 01:22:08 2010 Tags:

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.

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

[[!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.

Posted Fri Oct 8 01:22:08 2010 Tags: ?MtnSummit/2008

Contact: MarkusWanner, DerekScherger

The goal of the nuskool branch is to replace netsync with a faster, DAG based algorithm.

Status: Stalled

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

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

Posted Fri Oct 8 01:22:08 2010 Tags:

Contact: all Developers

Main branch containing the monotone ikiWiki.

Status: don't merge with net.venge.monotone!

Posted Fri Oct 8 01:22:08 2010 Tags:
Quick Links:     www.monotone.ca    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status