monotone implementation road map
Release 0.99 / 1.0 - Fall 2010
| Description | More Info | Branch(es) | Status | |
|---|---|---|---|---|
| Extended selectors | MagicSelectors | nvm.extended-selectors |
completed, merged | |
kill_certs_locally |
n/a | nvm.kill_certs_locally |
completed, merged | |
| Netsync URI refactoring | n/a | nvm.connection_info_cleanup |
completed, merged | |
| Fix mtn:// sync | n/a | nvm |
completed | |
Fix rename foo foo |
n/a | nvm.bugfest-2010.29484-rlevitte |
completed, merged | |
| Disapprove multiple revisions | n/a | nvm.tkoskine.disapprove-multirev |
completed, merged | |
| Less verbose restrictions | savannah | nvm.restriction-fixes |
completed, merged | |
| Fix anonymous remote_stdio | savannah | nvm |
completed | |
| Branch name deprecation | monotone-devel | nvm.deprecate_weird_branch_names |
completed, merged | |
| Overwritable, negatable options | OverwritableNegatableOptions | nvm.options |
completed, merged | |
| Key management in automate | savannah | nvm.key_management |
completed, merged | |
| Dump man page from command tree | n/a | nvm.man-page* |
completed, merged | |
| Fix changelog editor issues | monotone-devel | n/a | not started | |
Release 1.x - 2010 / 2011
| Description | More Info | Branch(es) | Status | |
|---|---|---|---|---|
rename --guess |
n/a | nvm.rename-guess |
somewhat abandoned | |
| Clean workspace from unknown / ignored files | n/a | nvm.tkoskine.purge |
in development | |
| netsync --anonymous | n/a | nvm.bugfest-2010.28805-rlevitte |
in development | |
| Colored diff and log output | n/a | nvm.colored-diff |
in development | |
Release 2.0 - 2011
| Description | More Info | Branch(es) | Status | |
|---|---|---|---|---|
| Remove netsync's SERVER [PATTERN] syntax | n/a | n/a | not started | |
Not targeted
| Description | More Info | Branch(es) | Status | Major Version Change | |
|---|---|---|---|---|---|
| Sane SQLite locking | monotone-devel | n/a | not started | No | |
| Policy Branches | VersionedPolicy | nvm.tbrownaw.policy-branches,nvm.experimental.policy-branches* |
in development | Yes | |
| Daggy refinement | DagBasedRefinement | n/a | not started | No - netsync version negotiation | |
| SSL for netsync | n/a | n/a | not started | No - netsync version negotiation | |
| Partial pull | PartialPull | n/a | not started | No - netsync version negotiation | |
| Let die-die-die die | n/a | n/a | not started | Yes - revision format change | |
| 'mountpoint' node type | n/a | n/a | not started | Yes - revision format change | |
| Command naming cleanup | n/a | n/a | not started | Probably - if sufficiently extensive, or it touches the automate commands | |
| Netsync preview | n/a | n/a | not started | No - I don't think this would need any on-the-wire changes at all | |
| Update conflict handling | UpdateConflicts | n/a | not started | No | |
Allow - and _ interchangeably in
commands and options |
n/a | n/a | not started | No | |
| "Packed" revisions | monotone-devel | n/a | not started | Probably not | |
Original ROADMAP file, slightly updated for current monotone
This document gives a rough overview of features and changes planned for the future of monotone development. It does not spontaneously include bug fixes. We endeavour to fix bugs when possible, throughout the development cycle. When a specific class of bugs is targeted for focus in the roadmap, it is noted here.
The roadmap does not include release points, because it is our intention (though at times not our demonstrated behavior) to stick as close as possible to time-based releases, once per month. Even if we happen to hold up a release for some unforeseen reason -- usually lack of available effort -- the plan is to operate in a time-based cycle.
Note also that the roadmap is (broadly) conservative. The goal with monotone is to produce a stable tool which works fast, reliably, predictably, and helps users manage their ever-growing collections of diverging data.
ROADMAP
- tidy up major build/use-breaking bugs in win32, BSD, OSX
versions
- fix codepage-/non-utf8-related problems
- improve netsync error reporting code
- one part: many 'I's should be 'require's.
- move output formatting to lua hooks
- implement improved ACL/permission system for default trust rules
-
continue the implementation of "merge into workspace"
( probably call it "1.0" or "stable" around here )
-
work on GUIs and web UIs
- "merge before commit" (CVS-style online commit-coordination)
- bidirectional mirroring between monotone and CVS/SVN/arch
- "hash-migration" technology for scenarios where SHA1 falls
- ease long-term maintainance by writing up a real hacking guide (.texi, based on expanded HACKING file, a guided tour of code, and a thorough description of the more complicated algorithms) for new maintainers.
there are also some issues which are very regular, mundane, tedious, boring, but ultimately pretty mechanical. they need doing too.
JANITORIAL
-
librarification: several discrete steps, each mechanical, best to do a compile and commit after each.
- make a struct for each file.
- make every "plain" function in the file a static member of the struct
- make every global/static object in the file a static member of the struct
- make every reference to an out-of-file global/static happen via a static reference stored inside the struct, initialized at load time
- remove static-ness of references, from file to file, until there is a single root value for the whole application
(nb: this is not to say that monotone will every be packaged or provided as a library, simply that it's a little more flexible, and easier to see dependencies between modules, when you have things structured this way. we should have been doing so all along, but we were lazy)
-
possibly purge the whole packet-reading/writing stuff.
-
implement a pager so that long outputs get automatically paged if the terminal is intelligent enough to support this feature. cogito does this and it is very convenient. (how many times have you had to rerun a command just to pipe it to more(1) or less(1)?)
-
abstract the way arguments are checked when running a command. given that each command has a "params" member that describes its syntax, it seems fairly easy to homogenize its syntax, write a simple syntax parser for it and use it to sanity-check the command line given by the user. this could remove a lot of inconsistencies in error messages that exist in the current code because, at the moment, each command is reponsible of checking the 'args' size and format to report errors.
-
remove the special-casing of top-level commands. ideally they should behave just like any other command that accepts subcommands (e.g. 'list'). however, the command lookup routine has to support ignoring the top-level command if not given to preserve compatibility and not complicate things a lot. e.g. 'mtn informative list' should be the same as 'mtn list'.
-
modify the CMD_AUTOMATE macro so that it can document all the details of an automate command (input, output, first version, etc.). the idea is to move all the documentation for automate commands (currently placed in comments in the code) to the online help system.