Re: [Monotone-devel] Re: Proposal for human readable revision IDs

[Daniel Carosone]

I don't have any problem with hex revision id's.  Punctuating them
differently doesn't really change the issue; it's not about how easily
I can read a string of digits, it's about how meaningful what I read
is to me.

The reason I don't care is that I shouldn't need to use (ie, type or
remember) the hex id's, almost ever.  We have tags and branches and a
sophisticated selector system to find revisions.

What puts (especially new) users off, and fuels this recurring debate,
is that monotone's *output* always tells the user about hex
revisions. As well as failing to convey more meaningful information we
have available, this fails to train users to think about more symbolic
revision selectors.

This is intensely apparent in the context of "annotate".  monotone's
annotate is funtionally correct, but ~useless for the end user's
common need.  Consider that an early implementation of "cvs annotate"
was called "cvs blame" and you see the critical annotations for each
line:
  who last changed it, and when?

An explicit revision id annotation, whether hex or cvs 1.345.3.2, is
useful mostly as a reference to pull out that version for closer
inspection (in a web frontend, it's a hyperlink, and even for cvs I
don't look much at the rev number).

So with this in mind, we might try to add columns to the annotate
output for the relevant author and date cert, like a web frontend
would for example.  But I think we can do better than that.

We should use those certs to produce a selector string, and present
that string in place of the hex id whereever revisions are printed
(not just in annotate).

Again taking the cue from annotate, I would suggest these take a
generic form like:
 a:.../d:.../012345

To convey significant information, we could also add /t:.../ selectors
in wherever tags exist on that revision (at the risk of producing very
long selector strings).  The string could be shortened, too; only the
most recent tag could be preferred, the author could be truncated at
'@' if that's still unique, the date could be shortened if that's
still unique, etc.

We need to derive a unique selector, including one that will be
relatively stable against revisions we haven't yet seen that might
arrive in a later sync. This just means we add more digits of the hex
id at the end, at worst falling back to the full hexid.

Since there's room for preferences here, this would be the job of a
pretty-print hook. The hook would be passed a list of all the certs
that apply to the revision, and assemble a string like above. The
output of the hook would be tested to make sure it selects only the
intended revision; if not monotone would just print the hexid, as now.

--
Dan.

pgpgAJMtiaiCr.pgp
Description: PGP signature