Re: [Monotone-devel] Re: user-friendly hash formats, redux

[Oren Ben-Kiki]

On Friday 10 December 2004 10:35, Nathaniel Smith wrote:
> > The +n/-n notation has a problem when there's a fork (or merge).
>
> Yeah, but this is a separate and solvable problem.

I disagree its a separate problem. Proof: If you solve the +n/-n 
problem, start at first revision of the branch. Give each other node 
the "+n" notation that gets you there. Poof - friendly revision ids.

Solvable... now that's debatable. In a truly distributed system where 
even the same author may be creating inconsistencies, there's no 
"perfect" solution. There are only "reasonable" ones.

> > For this to work, it is necessary to be able to retract a tag from
> > a revision (for "renumbering"). Is this possible today? There's no
> > --untag command... I suppose that being able to retract any cert
> > could cause problems, but the restricted case of tags makes more
> > sense.
>
> There's no --untag command because it's impossible to delete a cert.

I guess that's where the name "Monotone" comes from, right? I can see 
how that makes sense, but for tags it sucks Dyson spheres through 
capilary tubings.

For one thing, it is very convenient to have "latest-<property>" tags. I 
suppose this can be achieved with testresult certs, but it is much less 
convenient (can testresult keys have nice meaningful names, anyway?)

> The best you can do is to issue a second cert saying "err, never mind
> about that cert over there", but this hasn't been done because it has
> some drawbacks.  Suddenly every time you look up a cert, you have to
> go do another database lookup to make sure it hasn't been retracted
> (and presumably this can happen recursively or something), and I
> don't even have the slightest idea how you deal with the trust issues
> (i.e. specifying whether person A can retract person B's cert)...

I don't see how this needs multiple lookup or gets recursive. Looking up 
a cert is a query; set things up so that it picks the latest matching 
cert (instead of the only one today). It is still a single query 
returning a single cert.

As for key trust issues - overriding a cert and creating new head 
revisions in a branch raise the same issues. Use the same solution for 
both - only the cert creator may override the cert; if someone else 
attempts to, the original owner has to sign on it.

> > My favorite character here is be '+': 2004-12-10+13:12:45...
>
> Why not "_" or "." or ","?  They're much closer to a space in
> readability, easy to type at the shell, and have no other meaning in
> dates...

Personal choice. ',' and '_' just look ugly. '.' looks too much like a 
float. '-' and ':' are confusing. '@' is ambiguous with E-mail 
addresses. And so on. That's another reason we went for a simple space 
in YAML - it is non-contraversial and the most readable. Of course, we 
don't have the command-line-argument problem...

I think your best bet is to emit log file timestamps using a space, and 
allow both (quoted) space and T/t to be specified in the command line, 
you'll be OK.

BTW, what do you do about timezones? Again, your best bet is to always 
emit them in UTC (add a " Z" at the end), but allow any time zone to be 
used on the command line. The command-line default might be the local 
time zone, I suppose...

Timestamps are a PITA :-(

Have fun,

 Oren Ben-Kiki