Generalize reporting [was (controversial) Renaming 'bzr' => 'bz']

[John Yates]

Ian Clatworthy wrote:
> Wichmann, Mats D wrote:
> > Robert Collins wrote:
> >> What do you think of having bzr ls be the preferred way to query
> >> these individual things? e.g. 
> >>
> >> bzr ls --ignored
> >> bzr ls --removed
> > 
> > I could get used to that - doesn't seem a bad approch.
>
> Yeah - I like it a lot. It's a bit of extra typing but that's no drama
> in a script. It could also generalise nicely to get just the filtering
> of interest, e.g.
>
>   bzr ls --removed --added

ClearCase had a very nice approach to the general problem of reporting.
Mercurial seems headed in the same direction though they have not taken
it as far yet (see Chapter 11 - http://hgbook.red-bean.com/hgbook.pdf).

The ClearCase approach was to provide a clean framework for expressing
fairly arbitrary queries and for formatting the results.  A certain
number of the most common queries were exposed via a layer of aliasing.
Reporting was the purview of the show command:

  show <domain> <criteria> <format>

Mercurial has embraced programmable formatting and, based on my hazy
memories of ClearCase, I would say has taken it significantly farther.

In the limit I envision presenting each domain as an SQL queriable table.
Even without any join functionality an SQL select query still offers a
very rich set of capabilities: where conditions, group by, order by,
limit, etc.  Combined with something like Mercurial templates and styles
this would satisfy nearly any integration or reporting requirement.

I have not looked at monotone but it would not surprise me if, because
their implementation is based on sqllite, they don't get most of this
functionality for free.

/john