FEATURE REQ: group common commands under 'ls' instead of separate commands

[Martin Pool]

On 13/09/05, John Yates <jyates at netezza.com> wrote:

> Let me suggest that this thread really amounts to an argument about the
> useful or basis set of queries that we want to support against a database
> and the formatting of the results.  The state of the DRCS and a user's
> working storage constitute the "database".  Every non-destructive bzr
> command is merely a query is disguise.  The many issues around specifying
> revisions (which has at times consumed this list) in database terminology
> are merely varying query restrictions.

Right; though at the same time we need to recognize that "oh, it's
just a database" is a level of understanding that should be optional. 
Novice users should be able to treat it just like cvs: diff, commit,
update, merge.

> ClearCase's ClearTool definitely exemplified this design perspective.
> ClearCase documentation describes both a "query language" and a "report
> writing" capability.  In reality these features are nothing more than
> subsets of the command-line syntax.  Instead of the SQL's SELECT verb
> ClearCase uses DESCRIBE and FIND.  Report writing is a fancy name for
> a format string introduce by a -fmt option.  The string can include
> tokens to specify rendering various attributes of the entities selected
> by the query.
> 
> It has been years since I used ClearCase.  Still I remember fondly
> composing queries that generated sequences of commands that I could
> redirect to a file and execute without any further editing.

Yes, I also used it a few years ago and was pleased by the database
and unixy aspects of it (and less pleased by other things.)

I think it would be great if we had a find command that could track
down revisions or files as you can do with cleartool.  ls is a small
step towards that, an alias for "find, in the working directory, all
files modified since the current head revision."

-- 
Martin