Below is the file 'ROADMAP' from this revision. You can also download the file.

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
- improve netsync error reporting code
  - one part: many 'I's should be 'require's.
- overhaul command-line option processing, perhaps use argp
- move output formatting to lua hooks
- integrate net.venge.monotone.ssh branch
- implement improved ACL/permission system for default trust rules
- implement "merge into workspace" approach to merging
- emacs integration

  ( 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
- an "agent" for storing decrypted private key in memory
- "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)

- as a side note: collect all the command-line options from global_sanity
  and app_state into a single options structure, just to improve
  legibility

- rewrite the testsuite in some form which does not generate
  a 6mb shell script. bonus points if it can run at a decent
  speed on windows (nb. fork() on windows is insanely slow)

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

- implement optional colorization of output for diffs and logs.  simplifies
  the task of reading diffs *a lot*.  see cogito's diff -c command.

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