Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

UI Issues


The goal of this page is as a scratch pad for me to keep track of UI issues. Particularly, I'm concentrating on things that, while they may be small to trivial, can be significantly annoying in usage, and indeed may just turn somebody off right away.

That is to say, primarily things that may not keep you from accomplishing your goal, but definitely make you or .

Essentially, "UI warts".

Micro UI Issues

  • Progress bars. This is a piece that heavily impacts first impressions of the tool, which makes it important.
    • Particular offenders are the branch/pull/push clan. At one point, the progress bars on branch and pull listed "X/Y revisions", which gave good indication of how much it'd done and how much was left, as well as some idea of how fast it was going. Currently, it just tells "phases", which tells the user nothing about what's going on. Too, the phases themselves are so uneven as to be useless; in pull, 99% of the time is spend in phase 1.

      • It's also nice to see after the pull how many mainline revs and total revs were gotten. Recent's pull no longer lists how many revisions were pulled at all; just the new head revno.

      • X-ref monotone's pull output.

  • Working tree awareness of what version it's at. It seems to track it in .bzr/checkout/last-revision, but you'd never know it from the UI.

    • Consequence: bzr revert will let you fling it around to various versions, but it doesn't keep track of where it is, which causes problems when you then try and revert to some other revision. This begs for update -r (see Bug 45719).

    • Not really related: there's no counterpart to bzr revno that returns just the revision-id. There's the hidden bzr revision-info, which gives you both (and is, of course, hidden).

  • Binary files make diff look wonky.

    % bzr diff
    === added file 'foo'
    Binary files foo        1970-01-01 00:00:00 +0000 and foo       2006-11-05 07:01:33 +0000 differ

    Perhaps "Binary file foo differs"? (71307)

  • upgrade still heavily thinks in a one-format world, and lacks something in user-friendliness. This applies also to other commands that can set format, like init. X-ref 89829.

    • Rollup format names have some issues. The names given to the individual formats in info, and the format name upgrade tells you when it finds nothing to do, don't look anything like the format names you hand to upgrade. (see also e.g. 90302)

    • When 'upgrade' finds nothing to do, it tells you about the control format, which is the LEAST likely to change (and so telling you it's already at the latest is unhelpful). It should probably talk about each of the 4 formats individually. (173061)

    • There's no way to tell what 'upgrade' will try to do, without letting it do its thing, after which it's too late to change your mind (see 89830).

  • Commands that do things cross-format (branch/push/pull being the most common cases) do conversion, but tend to do it silently, can take ages, and can do things like crossing the rich-root-Rubicon silently. At least 'starting' operations like branch should TELL you any time the source and destination repo/branch formats aren't identical. Ideally they should tell you more details (e.g., it can know that pack-0.92 vs 1.9 are quick and easy to interoperate, while 1.14 and 2a are not at all).

  • missing uses --reverse to show the log messages in "forward" order, while log uses --forward to mean the same thing.

    • In the same vein, other commands can do log-ish output (ex: pull -v), but don't necessarily give you all the output options/capabilities that log does. It Would Be Nice If(tm) somehow that could be generalized so that you could use those options anywhere that does something log-ish.

    • (243362)