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: 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<time,...>) 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: 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