Branches that are marked Work_in_Progress:
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?
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.
[[!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
Some experimental UI and doc tweaks, in attempt to make things more streamlined and friendly to new users.
setup is renamed to
--new-db switches, avoiding the need to
db init in
almost all cases. Tempted to rename
Todo: get feedback; update docs accordingly; write tests