QuickieTasks

quickie tasks

These are some small, uncontroversial tasks. As such, they're ideal for anyone who wants to get involved with the project; there's always some overhead with getting into a new code base, figuring out how things fit together, how to send acceptable patches, all that, and the quickest way to get through it is to make your first patch something small, so you don't also have to worry about complicated design issues at the same time. (Of course, some people do great just diving in; there's no rule that says you have to do this.)

So, here are some smaller tasks, that very much need doing, that fit the above bill:

• new commands mtn detach (which removes the _MTN directory from a workspace), and mtn attach -r <rev> (which turns a normal directory into a workspace at the specified location). These are useful for export/import type workflows.

• new developer's command mtn make_man_page that dumps out the --help texts in man page format. Update build process to use this command to generate a real man page and install it.

• header file audit (only #include things we actually use, use <iosfwd> when possible, etc.)

• mtn rename --guess -- try to figure out what files have been renamed by matching up missing and unknown files with the same checksums

• mtn list duplicates -- list files that have the same checksum (duplicate content) in a given revision (or the workspace)

• mtn clean --unknown --ignored to remove files of each type from the workspace; handy for a really aggressive "make clean", and for plaforms without xargs or where there might be spaces in filenames so that mtn ls unknown | xargs rm is hard or dangerous.

• mtn diff --ignore-whitespace

• make the diff header contain more helpful contextual information -- some thoughts are in this email. it might take a bit of discussion to figure out the nicest format

• 'db check' now includes a call to the sqlite PRAGMA integrity_check, but we need a test for this; check out Message-ID < 20060511064950.GC5025@frances.vorpus.org> in the list archives.

• more inodeprints UI -- maybe "inodeprints on/off/auto/refresh", where "auto" turns them on or off depending on the size of the tree (and is used by default at checkout time)?

• support for .mtn-template. This is a versioned file, that is used as the default for log messages. This might be helpful so you can put in fields for bug numbers, standardize your log message format, etc. Implementation is to make it the default value of _MTN/log. One tricky bit is that commits should be canceled if given an empty or _unchanged_ log message; currently they are canceled only on an empty log message.

• script that wraps monotone and gathers statistics on usage, that people could use to help us make UI decisions. Just recording commands would be good; taking notes on things like how many files were edited in a commit, whether any given merge or update had conflicts, etc. would be even cooler.

• make --debug output contain timestamps for each event, possibly with another option; this might help provide information about performance issues and where time is being taken between key steps.

• include tests in the test suite to ensure that various external tools (like tailor or buildbot) still work with us; perhaps track their integration code (eg, monotone.py from tailor) and attempt to keep it up to date with changes in HEAD.

• two-argument disapprove: should be some way to apply disapprove to a range of revisions, not just a single one. (basically just means committing the changeset diff(LASTREV,FIRSTREV) as a child of LASTREV.) be careful about merge nodes in the span to disapprove.

• add support for more merge tools -- SVK is one source of these, they support a number that we don't. see SVK/Resolve/* in their source tree.

• add a test for context diff output

• write a test for any bugs in the tracker labeled [NEED TEST].

• IN PROGRESS: Emacs code that makes C-x 4 a drop one into _MTN/log instead of ChangeLog. See ChangeLog

• mtn status -rREV and mtn checkout --nofiles; see this discussion and this one.

• automatic updating of the tutorial section of the texinfo docs so that program output, etc. is kept current

See also: InterfacesFrontendsAndTools that don't exist, but if they did they would make using monotone just that much more awesome.