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

[Oren Ben-Kiki]

On Friday 10 December 2004 12:17, Nathaniel Smith wrote:
> 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.

Number of nested forks, you mean (forking a fork). Simply forking off 
consequtive revisions doesn't cause the ids to be longer (foo.2.me.1, 
foo.5.me.1. etc.)

> Unfortunately, it's difficult to override the laws of mathematics for
> your pain...  what I meant is, we literally _can't_ delete certs.
> ...
> So you propose that each cert add a "generation" counter to it, and
> the highest generation always wins?

Timestamp, not generation counter.

> What do you do if there are multiple certs at the same generation?

The same user submitting two conflicting certs at the exact same 
(micro-)second? I guess that _could_ happen, but it doesn't really 
matter how you handle it. Choose the one with the lower hash code. 
Prompt the user. Shoot the user. Whatever ;-)

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

Hmmm. Good point. And a revision can have several tags. However, it is 
still doable.

Use a revocation cert (again, later timestamp overrides an older one): 
it identifies another cert and, well, revokes it. Have a boolean in the 
cert's record saying if it has been revoked. This boolean is updated 
when a new cert comes in (e.g. in a sync). You were right the first 
time - this update may be recursive (revoking a revocation), but it 
only happens during a sync (or when getting a new cert from the user).

When you _use_ certs, simply replace each "select cert where 
<condition>" with "select cert where <condition> and not <revoked>".

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

"Crippled"? isn't that a bit strong? The worse that happens is that you 
need to create a new branch. You retain all the revisions and history. 
Where's the damage? Besides, in a company settings, the branch "owner" 
key should be a role key rather than a personal key, so that anyone 
being hit by a bus doesn't cause even the (minor) inconvenience of 
changing the branch.

Personally, I feel that if I put my project on the Internet, I want to 
allow people to submit to it but I'm _very_ uneasy at the thought that 
anyone at all can create a new head revision for it. If someone wants 
to create a new, competing revision, he's welcome to create his own new 
branch. If he only wants to submit a bug fix to my branch, I feel it 
should be explicitly marked as a non-head revision and it should be 
left for me to decide whether I want to merge it or not.

If I understand you correctly, today if I commit a new revision into 
your db, there's no easy way for all the developers sync-ing with it to 
tell which head revision is the "official" one and which one is just a 
proposed bug fix. This happens a *lot* more often than you getting hit 
by a bus (god forbid).

If Monotone's position is that the contributor should have created a new 
branch in order to submit his patch, I guess can see that... but I 
setill need a way to enforce it - this is the Internet we are talking 
about. So again it boils to restricting which keys can be used to check 
in a revision in a branch.

It also seems much more convenient to have the notion of a "fork" 
_within_ a branch to capture the intent of "here's a patch you want to 
consider", and allowing tailoring commands for this common use case. 
For example, can I easily list all branches splitting off my branch 
that have not been merged back into my branch and that I have not 
(somehow) explicitly disapproved of? This is the equivalent of what a 
simple "monotone list forks" command would do...

This was so "obvious" to me that it has taken me a while to grasp 
Monotone doesn't allow me to do this sort of thing. I'm rather 
horrified by this...

Have fun,

 Oren Ben-Kiki