Branches that are marked Work_in_Progress:
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) 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