Re: [Monotone-devel] current to-do items

[graydon hoare]

Tom Tromey <address@hidden> writes:

> I've been making a list of oddities I've noticed, or things I couldn't
> figure out how to do.  I thought I'd send it for discussion and
> comment.  

this is great, really! 

I am reminded in situations like this of the first section in joel
spolsky's UI book, about how a lot of small irritations and
misbehaviors will drive you to hate a program, even if there's no one
thing which makes it unusable. I absolutely want to make monotone feel
smooth and responsive.

http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html

> "monotone foo" should print error, not usage
> should exit with status 1

really? I've no opinion on this, so .. I guess if you prefer.

> monotone update returns error if nothing to update

yeah, that's wrong.

> monotone stores keys in database
> but that seems fragile as the db is transient
> (Actually, per another discussion we've had, the db isn't necessarily
> transient.  I've changed my approach to be more careful about keys.)

well, I don't know what else to do about it. I think I don't want to
change this for the moment. I've heard people say that monotone
"shouldn't be in the business of key management", that it should be a
separate thing. but I've also seen a compelling pair of case studies:
email and ssh. email client authors, for whatever reason, decided that
key management should go in a separate program (PGP). ssh authors
decided that, no, key management was central to doing the job right,
so they would integrate it. the result is that 10 years later, very
few people (even counting amongst those who know how) use PGP-signed
email, but *everyone* uses SSH. even though there's no PKI or trust
web or anything with SSH, people generate and use reasonably good
public key crypto.

> email transmission seems most useful
> could configure client pretty easily?

yeah. just "mailto:address@hidden"; in the URL field, ignoring
the logical group name, or something of the sort. the more I consider
it, the more I would like this in the next release.

one thing to note, however, is that email doesn't provide much in the
way of replay, compared to depots or news servers. if you've received
an email once, then toast your database, it's not obvious how to tell
a client to "receive the mail again" unless you happened to keep the
mail. mail is a bit more transient. news servers and and depots

> monotone fetch should report what it is doing
> like wget or scp...

yeah. you think a '\r' based repeated-print-on-one-line status meter
is better, or a bunch of successive lines?

> "see standard output for details" - just remove this and the
> "**** error code 1" -- that output isn't useful

oh, I didn't write those. I agree they're stupid looking, they're an
artifact of boost's prg_exec_monitor, which is trapping signals and
win32 structured exceptions. I could, in theory, move the
prg_exec_monitor into monotone's private boost/ directory, and modify
it not to print that, or rewrite it myself.. otherwise I don't know
how to inhibit it.

you know, it used to print a stupid status message like that when
it ran *successfully* too; the first call to setenv() in monotone.cc
inhibits that, thankfully. maybe I should submit a patch to boost.

> prefix error messages with "monotone:"

ok.

> "monotone annotate"

this one is doable (the piecewise xdelta already knows some of the
logic, and there's a fair amount of piecewise line-diff processing
logic in cvs_import.cc as well) but it presents some UI issues.

1. what do you put in the annotation prefixes? sha1 codes? authors?
   authors+dates?

2. is your annotation in terms of storage, or ancestry?

3. should you do byte-ranges, or lines? line diffs are less precise 
   than the byte ranges the xdelta algorithm uses, but they're more
   readable.

4. what do you do with the fact that aggregation might mis-attribute
   authorship? for instance, if I collapse 10 versions by different 
   authors into 1, which author (and version number) to I attribute
   all those lines to? how do I warn the user that they're seeing an
   aggregation of changes?

anyways, it's all doable, it's just hard to figure exactly how to do
it right.

> maybe "monotone status" should print current base revision
> (is "sha1sum < MT/manifest" the supported way to get this info?)

agreed. also perhaps the current changelog cert, author and date.

> "monotone log" or something similar
> finding out what changed seems pretty difficult
> I've been running lscerts on each manifest key, one by one

agreed. but again, log presents some UI questions: how do you present
logs of forks and merges? depth first? breadth first?  how do you
indicate that one was a merge, or that you're currently looking at log
history on the left vs. right ancestor of a merge. there is not just
one linear history of a given file as in CVS -- each version might
have N parents.

> should "mv * monotone/" in monotone repository

you mean, you want the entries in the manifest of my current depot to
all start with monotone/...? why?

> rm foo.cc; monotone update
> should work

yeah, or something. as discussed in previous mail, that or revert. or
both.

> how to post changes already made to a local database?

yeah. I was thinking a three-step process:

  $ monotone patchset id1 id2 >packets.txt
  $ monotone enqueue url groupname <packets.txt
  $ monotone post

perhaps merging 2 or 3 of these into a "convenience" function would
also be good, but keeping them available as separate steps makes it
usable for other situations (reading the patchset, modifying it,
concatenating several patchsets, enqueueing 1 patchset for multiple
destinations, etc)

-graydon