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 build/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- overhaul command-line option processing, perhaps use argp
28- move output formatting to lua hooks
29- integrate net.venge.monotone.ssh branch
30- implement improved ACL/permission system for default trust rules
31- implement "merge into workspace" approach to merging
32- emacs integration
34 ( probably call it "1.0" or "stable" around here )
36- work on GUIs and web UIs
37- "merge before commit" (CVS-style online commit-coordination)
38- bidirectional mirroring between monotone and CVS/SVN/arch
39- an "agent" for storing decrypted private key in memory
40- "hash-migration" technology for scenarios where SHA1 falls
41- ease long-term maintainance by writing up a real hacking guide
42 (.texi, based on expanded HACKING file, a guided tour of code,
43 and a thorough description of the more complicated algorithms)
44 for new maintainers.
48there are also some issues which are very regular, mundane, tedious,
49boring, but ultimately pretty mechanical. they need doing too.
54- librarification: several discrete steps, each mechanical,
55 best to do a compile and commit after each.
56 - make a struct for each file.
57 - make every "plain" function in the file a static member of the struct
58 - make every global/static object in the file a static member of the struct
59 - make every reference to an out-of-file global/static happen via a
60 static reference stored inside the struct, initialized at load time
61 - remove static-ness of references, from file to file, until there is a
62 single root value for the whole application
64 (nb: this is not to say that monotone will every be packaged or
65 provided as a library, simply that it's a little more flexible,
66 and easier to see dependencies between modules, when you have
67 things structured this way. we should have been doing so all along,
68 but we were lazy)
70- as a side note: collect all the command-line options from global_sanity
71 and app_state into a single options structure, just to improve
72 legibility
74- rewrite the testsuite in some form which does not generate
75 a 6mb shell script. bonus points if it can run at a decent
76 speed on windows (nb. fork() on windows is insanely slow)
78- possibly purge the whole packet-reading/writing stuff.

Archive Download this file



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