[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: user-friendly hash formats, redux
From: |
Oren Ben-Kiki |
Subject: |
Re: [Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Fri, 10 Dec 2004 13:39:57 +0200 |
User-agent: |
KMail/1.7.1 |
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
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Patrick Mauritz, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Brian P. Campbell, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/10
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Matthew A. Nicholson, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Phil de Joux, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Patrick Mauritz, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Matt Johnston, 2004/12/10
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Zack Weinberg, 2004/12/07
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/07