#
#
# patch "wiki/RoadMap.mdwn"
#  from [4c332cd19ef0c4ce2a6005ee54f515539b0cde98]
#    to [29bd75c9deb34be6611d6301fd1fa5ffa54b3ddf]
#
============================================================
--- wiki/RoadMap.mdwn	4c332cd19ef0c4ce2a6005ee54f515539b0cde98
+++ wiki/RoadMap.mdwn	29bd75c9deb34be6611d6301fd1fa5ffa54b3ddf
@@ -89,3 +89,97 @@ State: 0%
 Entry page(s): ...
 
 State: 0%
+
+# 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)?)
+
+- 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.