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:

  • write a git/svn/hg/ importer - presumely git is the most important one nowadays, since most other SCMs can dump their history in git's fast-export format

    • git's fast-export format doesn't carry enough branch information, as monotone's branch model is much more information-rich than git's -- ignoring reflogs for a moment, which aren't used by git-fast-export and aren't synced between git repos. In principle the fast-export format could carry the information, but it doesn't. reflogs may also not be available everywhere, so we'll just have to accept that git is "lossy" and find a best solution.

    • The fast-export format doesn't carry unique identifiers per commit, so it might make more sense to import directly from the git repo. We loose flexibility (e.g. hg --> mtn would have to go through git), but can carry over more information (think x-git-commit-id certs).

    • On the other hand, we shouldn't need to worry about duplicate commits as the exporter should track that.

    • Just ran another test with git-fast-export. Turns out you can't export a subset of a branch (say, the latest commits). Well, you can, but try exporting just the tip of your branch: You'll end up with a single commit that adds all your files. Basically git-fast-export always assumes the first commit to come out of nothing, even if it really doesn't.

      • Based on this, we really can't work with the fast-export format for partial imports, and partial imports would be really nice to have. So here's plan B: import directly from git.

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

    • mtn detach: Refuse to remove the directory if there are unknown files inside. We don't want to make it too easy to loose data.

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

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

  • 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 with the tag Task:NeedTest.

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