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

[graydon hoare]

Derek Scherger wrote:

> 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?

yeah. I think I like the suggestion which came up here that --verbose be 
renamed --debug, and --verbose be used as a flag which means "tell me 
slightly more than you otherwise might". the current --verbose tracing 
is so verbose as to be meaningless to a non-developer.

> 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 was thinking "explain", as in "explain update", "explain merge", etc.
sort of a moral equivalent to "cvs -n ..."; but I'll listen to other 
ideas. haven't given it much thought.

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

yeah, that sounds handy.

> I was also thinking about 
> showing the patch summary (again with something like log --verbose)

yup.

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

yes, me too. these changes will bring a welcome improvement to the sense 
of "what the hell is going on" which sometimes occurs with distributed 
development.

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

sound reasonable.

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

heh, well, that would be handy if we hadn't stolen "/" as a selector 
separator (and if there weren't so many files in the top level dir of 
most projects, with no "/" in their pathname).

I'm thinking that this issue needs to be postponed for, or at least 
thought of in concert with, the issue of general "restrictions". we need 
a way to work from a subdirectory of monotone (only merge it, only show 
diffs in it, only update it, etc) as well as from an arbitrary subset of 
files. something tells me the UI for that and "files selected from a 
manifest" ought to be the same.

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

neat. see above. I'd love to see some movement on a general restriction 
mechanism. I think it needs to be little more than a set of file names 
or patterns held in app_state, and used to filter manifests during 
construction.

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

no, that sounds good (especially if we make an option called --debug; 
never good to have a command with the same name as an option)

thanks for all these good suggestions! for those things you don't have 
working versions of yet, file them as bugs if possible so they're not 
forgotten.

-graydon