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

[Nathaniel Smith]

On Fri, Dec 10, 2004 at 11:15:28AM +0200, Oren Ben-Kiki wrote:
> 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.

Err... I question that you can solve it and end up with something
_friendly_... any system I can think of the length of the notation
grows linearly with the number of forks, making it horrendous for
describing long distance relations.

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

Err, that's a problem with revision ids.  It's not a problem with
coming up with a +n/-n kind of notation.  That's why I was using the
word "solvable" to distinguish the latter from the former :-).

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

Actually, no; Graydon should probably stick this in the FAQ or
something, because ATM it's completely obscure...

AIUI, it comes from, In the Beginning, one of the main goals for
Monotone was that you could use something like testresult certs to
ensure that 'update' always monotonically improved your working copy.
Of course then the ability to commit against a non-head revision is
necessary for this to be useful, etc...

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

I feel your pain.

Unfortunately, it's difficult to override the laws of mathematics for
your pain...  what I meant is, we literally _can't_ delete certs.  We
can try to do workarounds for this, like I discussed, but we can't
delete them.  (I guess actually we could have some sort of cert that,
when your database read it, it automatically wiped some other cert
from storage.  But this is a really terrible horrific idea on all sorts
of levels.)

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

So you propose that each cert add a "generation" counter to it, and
the highest generation always wins?

What do you do if there are multiple certs at the same generation?
What do you do if you want to issue multiple certs of the same type?
(E.g., it's perfectly legal for a revision to be on multiple branches,
for a revision to have multiple testresults, etc.)

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

This runs into the same problem as creating new head revisions --
having unique owners is a terrible idea, because it creates a massive
single source of failure.  If someone loses their key, or leaves a
company, or is on vacation, or has dropped off the face of the earth,
suddenly your VCS is crippled.  And all of these are extremely common
events.

-- Nathaniel

-- 
- Don't let your informants burn anything.
- Don't grow old.
- Be good grad students.
  -- advice of Murray B. Emeneau on the occasion of his 100th birthday