[Monotone-devel] Re: bug reports / first impression

[Derek Scherger]

graydon hoare wrote:
> not doing this, because I want it to be usable as input to xargs. eg. 
> monotone ls missing | xargs monotone revert.

Ok, that sounds pretty reasonable. Would --verbose (or something equivalent and not 
already taken) also be reasonable to add more info to a missing list (and other commands) 
perhaps?

> > On the "list" front, I've also been wondering whether "heads" should 
> > be "list heads" too.
>
> haven't added this one; not fundamentally opposed, but in general I'm 
> thinking of *reducing* the chatter in command names, not expanding it. 
> eg. considering changing "monotone ls missing" to just "monotone missing".

This sounds good too. Perhaps status should just list missing files in the 
patch summary?
Again a --verbose switch to status seems like it might be useful.

> you'll also notice I've committed changes which remove the 
> (file|manifest) arguments in all but one place (cat), since I'm phasing 
> out file certs, most places it used to be necessary were cert related, 
> so it's no longer needed. nobody seems to use file certs, and it just 
> complicates matters. fewer ideas to explain == better.

Excellent -- less to type! How about cat just looks for both files and manifests with the 
specified id and cats out whatever it finds if it's unique? There doesn't seem to be any 
real reason to require me to tell it what kind of id it's looking for does there?

How are you going to handle file ancestry without certs?

More thoughts on commands -- if you're interested in my 0.02 ;)

I was thinking about "log history" and "log updates" to show changes backwards in time and 
forwards in time but this seems to be counter to the direction you're heading. Where are 
you going with listing changes thath have happened but that I don't have in my working copy?

I've added the display of the ancestor id(s) to log in my working tree in an attempt to 
make it easier to see some more detail about changes but I'm not sure if this is helpful 
or not. I was also thinking about showing the patch summary (again with something like log 
--verbose) between versions to get some more detail and for a really detailed listing 
showing the actual diffs might be good too. Personally I'm finding that seeing what has 
changed and visualizing what's available in the database to be somewhat difficult.

I've also currently added aliases for update (up); commit (checkin and ci); and status 
(st) in my working tree. Any thoughts on these?

I really like the new selector stuff and was wondering whether there should be a file (f:) 
or perhaps path (p:) type of selector that matches things with /'s and other file type 
characters to look up an id in the current manifest.

Along the lines of path/file selectors I've got a preliminary file diff command that's 
completely separate from the current diff command until some sensible syntax comes to mind.

On the ls missing type of commands I was wondering whether the debug command should be 
something like db execute 'sql' but again this may be going against your current direction.

--
Cheers,
Derek