monotone Mtn Source Tree


2This document gives a rough overview of features and changes planned
3for the future of monotone development. It does not spontaneously
4include bug fixes. We endeavour to fix bugs when possible, throughout
5the development cycle. When a specific class of bugs is targeted for
6focus in the roadmap, it is noted here.
8The roadmap does *not* include release points, because it is our
9intention (though at times not our demonstrated behavior) to stick as
10close as possible to time-based releases, once per month. Even if we
11happen to hold up a release for some unforeseen reason -- usually lack
12of available effort -- the *plan* is to operate in a time-based
15Note also that the roadmap is (broadly) conservative. The goal with
16monotone is to produce a stable tool which works fast, reliably,
17predictably, and helps users manage their ever-growing collections of
18diverging data.
24- tidy up major buid/use-breaking bugs in win32, BSD, OSX versions
25- improve netsync error reporting code
26 - one part: many 'I's should be 'require's.
27- reimplement major surgery :(
28- overhaul command-line option processing, perhaps use argp
29- move output formatting to lua hooks
30- integrate net.venge.monotone.ssh branch
31- integrate net.venge.monotone.botan branch
32- modify database code to use sqlite3 pre-parsed queries, blobs
33- change netsync to globbing branches, not using collections
34- implement improved ACL/permission system for default trust rules
35- implement "merge into working copy" approach to merging
36- emacs integration
38 ( probably call it "1.0" or "stable" around here )
40- work on GUIs and web UIs
41- "merge before commit" (CVS-style online commit-coordination)
42- bidirectional mirroring between monotone and CVS/SVN/arch
43- an "agent" for storing decrypted private key in memory
44- "hash-migration" technology for scenarios where SHA1 falls
45- ease long-term maintainance by writing up a real hacking guide
46 (.texi, based on expanded HACKING file, a guided tour of code,
47 and a thorough description of the more complicated algorithms)
48 for new maintainers.
52there are also some issues which are very regular, mundane, tedious,
53boring, but ultimately pretty mechanical. they need doing too.
58- fix up the namespace issue: add a "using std::foo" for each foo
59 used in the file, and strip "std::" from the uses. remove
60 "using namespace foo" from everywhere. likewise boost.
62- librarification: several discrete steps, each mechanical,
63 best to do a compile and commit after each.
64 - make a struct for each file.
65 - make every "plain" function in the file a static member of the struct
66 - make every global/static object in the file a static member of the struct
67 - make every reference to an out-of-file global/static happen via a
68 static reference stored inside the struct, initialized at load time
69 - remove static-ness of references, from file to file, until there is a
70 single root value for the whole application
72 (nb: this is not to say that monotone will every be packaged or
73 provided as a library, simply that it's a little more flexible,
74 and easier to see dependencies between modules, when you have
75 things structured this way. we should have been doing so all along,
76 but we were lazy)
78- as a side note: collect all the command-line options from global_sanity
79 and app_state into a single options structure, just to improve
80 legibility
82- split into multiple files, one for each group of
83 commands (or even one per command).
85- rewrite the testsuite in some form which does not generate
86 a 6mb shell script. bonus points if it can run at a decent
87 speed on windows (nb. fork() on windows is insanely slow)
89- possibly purge the whole packet-reading/writing stuff.

Archive Download this file



Quick Links:    -     Downloads    -     Documentation    -     Wiki    -     Code Forge    -     Build Status