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

[Oren Ben-Kiki]

On Monday 06 December 2004 06:46, graydon hoare wrote:
> ... I was assuming that we'd carry
> on telling people that hashes were the "global" ID to use, when
> discussing revisions outside your own database. but maybe that
> assumption is not so good?

IMVHO, it isn't. Hashes must be kept as the fallback/internal mechanism, 
sure. But a human-friendly id is necessary for human activities, which 
include talking to one another.

> > You can avoid it, with a price: have a strong notion of a branch's
> > "main line" (or "trunk").
>
> ...
>
> while I'm not completely sold on the notion yet, another reason this
> might be a good idea to introduce is that it makes interoperation
> with "single headed" VC systems easier.

Good point.

> I'm honestly at a bit of a loss on how to implement that, though.

You already have a signed branch cert. Build on that.

> the 
> only thing which I can imagine is a 3rd party serializer -- some
> online number-dispenser -- which sounds sort of like a central point
> of failure.

No, there's no need for this, I think. It works like this:

- Create a branch, use a branch cert. Its signed by your key.

- When you commit a revision, have a flag "--main"/"--fork" controlling 
the type of cert you write. A "main" cert allows you increment the 
revision id:

    incr(N) = N+1
    incr(<whatever>.N) -> <whatever>.N+1

A "fork" cert means you also add a fork tail to the id, so you get 
incr(base).<you>-1.1. If you fork the same revision twice, your next 
fork is incr(base).<you>-2.1 etc. Make incr(base).<you>.1 a shorthand 
for incr(base).<you>-1.1 and only print the full '-1' form in log files 
etc. if there is also a '-2' fork in the database.

Note that --main vs. --fork apply even when committing a revision 
derived from a forked revision. If I start with 3.me.1, --main means I 
create 3.me.2, --fork means I create 3.me.2.me.1.

This is compatible with CVS, because you use numbers for the forks; it 
is also more readable because the added user name makes it clear what's 
a version number and what's a fork. Win-win.

- Sync. When you sync, you may have a problem with conflicting certs. If 
two revisions claim to be the main continuation of the same revision, 
you emit a warning, and decide which to believe and which to demote to 
a fork. Here you use the fact that certs are signed, and base this 
decision on the keys used. Prefer the branch/fork owner's key above the 
rest. If the owner conflicts himself assume first is main, all others 
are fork.

(BTW, I find it hard to believe this is the only case where conflicting 
certs are a problem...  This is a whole separate issue from revision 
ids, really, it touches on how to manage security in a distributed 
database. PGP solves it with a "web of trust". Black/white lists also 
come to mind. How does Monotone address this?)

At any rate, sync could renumber some revisions, but only if people 
misbehaved, you get a warning, and you can fix the problem by playing 
with certs.

- The default flag to use on commit (--main or --fork). This is tricky. 
Again, I suggest an owner-based default. If I signed the original 
branch (or fork) cert, everything I commit will be --main unless I 
explicitly say --fork. Other people's revisions are --fork by default 
(in fact, I think they _must_ be --fork because they can't sign the 
branch cert anyway - they don't have the key). Further commits don't 
re-fork because they are now the owner of the "fork" they are 
committing to.

So, it all works without a central authoritty for revision ids. Or, 
rather, each branch/fork owner's db acts as the central authority for 
that branch/fork, so you get a "distributed centralized" authority.

> ... it would be a very "soft" form of 
> failure, since it would only affect the names you call things by, not
> the things you can do with those names.

Yes; all conflicts/problems/etc. don't harm the DB, just the 
human-readable revision ids.

Have fun,

 Oren Ben-Kiki