[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: user-friendly hash formats, redux
From: |
Oren Ben-Kiki |
Subject: |
[Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Mon, 6 Dec 2004 08:57:57 +0200 |
User-agent: |
KMail/1.7.1 |
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
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Derek Scherger, 2004/12/04
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/04
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/04
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Christof Petig, 2004/12/06
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/05
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Derek Scherger, 2004/12/05
- [Monotone-devel] Re: user-friendly hash formats, redux, John S. Yates, Jr., 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Tim Woodall, 2004/12/06
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/06
- [Monotone-devel] unique repository ids, Nathan Myers, 2004/12/06
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/07
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/09