[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 12:59:14 +0200 |
User-agent: |
KMail/1.7.1 |
On Friday 10 December 2004 11:09, graydon hoare wrote:
> ... we've been over this before. it usually boils down to some
> variation (synchronous or asynchronous) of having a "branch owner" --
> person, robot, discriminated server -- issue a special linear cert.
> this unfortunately centralizes a failure case, and is not robust
> against backup/restore and multiple-issue errors on the case of the
> owner.
Hmmm.... I'm not certain I see the problem...
> unless oren has some new idea about how to establish a stable, robust
> linear subgraph, I propose we just let the whole topic drop for a
> while.
See below for some thoughts (and I'll then drop the issue :-)
> we've been running around in circles all week, and not come up
> with much new since the last time this was raised 6 months ago.
I guess my timing sucks... I wasn't aware of this history. I'll just
ramble a bit about the centralization issue (hoping I'm not repeating
old points from 6 months back) and will then back off.
I don't see the "centralization" here - either I misunderstand what you
mean by it, or I misrepresented my proposal. I'll try addressing it
anyway:
Yes, whenever I create a BOF (branch or a fork) there's a cert
identifying me as the owner. Only my key can be used to advance the
head revision of this BOF. This gets you the nice "linearized graph"
you spoke of. By default, as the owner of the BOF, any commit I make
advances the BOF version number, but I can explicitly create a sub-BOF
using "--fork".
If a bus hits me, the BOF is frozen forever - is this what you mean by
"central failure case"? I thought this is already the case today: you
need a specific key to sign a branch cert. Did I misunderstand, or is
there a subtle difference I'm missing?
Note that anyone at all can commit revisions into a BOF, even if he
doesn't have the owner's key. It is just that these revisions are in a
separate fork. So, if I have foo.1, foo.2 etc., someone else starting
with foo.3 would commit foo.4.him.1. Similarly, if a third developer
forks off foo.4.him.2, she creates foo.4.him.3.her.1, etc. This is all
automatic and gives you a structured, linearized graph.
Each branch is intended as an alternative version (e.g., old release
maintanance vs. new development, alternative design approaches, etc.).
In contrast, the intent of forks is to suggest patches or enhancements
to the branch; the branch owner chooses whether to merge them to the
main line. This means that forking a fork would be very rare. Still, if
it does happen, the same rules apply; Only "him" can merge
foo.4.him.3.her.2 into foo.4.him.5.
So yes, in this sense the BOF owner is a "centralized authority" - he
gets to choose what's "in" and what's "out". To me this is an obviously
vital feature. If this goes against the philosophy of Monotone, then it
isn't for me...
You can easily escape from someone else's control, by creating your own
branch to play god in. I might even merge your branch revisions into my
branch if I choose to - it is easy enough. In my view, the whole
_point_ of having both "branch" and "fork" is to clearly define the
"scope" of ownership/coherence/linear-development/etc.
I see two typical use cases here:
- "personal": There's a single branch owner. Its his project (or branch,
anyway), and he probably does most of the work. Other people submit the
occasional patch, bug fixes etc. as a fork (foo.9.contributor.1), which
the owner can either simply ignore or choose to merge to a main line
revision (foo.13). In this case, the owner can use his personal key as
the branch owner's key; whenever he commits a revision, he advances the
number from foo.n to foo.n+1.
In this case, the owner may be creating his own forks to denote "trying
things out" so contributors will know not to build on them (unless they
mean to). To do this, he needs to use --fork to express his intent. If
he doesn't, and he works on separate machines, and he doesn't sync
them, he'll cause some renumbering, but there's no other harm done.
- "Team": There's a team of developers collaborating on a branch. They
generate an owner's key but each developer uses his own personal key to
commit revisions. Someone wears the "owner's hat", possibly on
rotation, and is responsible for creating new foo.n+1 revisions by
merging some foo.m.developer.1 revision into the main line.
Presumably, the guy wearing the hat is responsible and doesn't
maliciously cause revision renumbering, just like he doesn't commit
junk revisions into the main line. Note that the team can be completely
distributed, and no db is "central". The db of whoever "wears the hat"
works as the "authority", but it isn't a "failure point"; if it is
nuked, any other developer can pick off the hat and continue the
branch.
In a corporate setting, there would be a formal workflow process using
testresult certs to express things such as testing, code reviews, QA
team approval, and whatever else red tape corporates find useful. Any
such workflow can trivially guarantee 100% that no version renumbering
is ever done, and that no failure of a single machine will cause
irreversible data loss.
In neither scenario is there a need for one special db to act as central
authority, in the sense that if I want to _create_ a patch to your
"personal" branch, or create a new revision in a "team" branch, I can
do so on my laptop on a bus without any connectivity whatsoever. I'm
also guaranteed that any revision ids I'm creating on my laptop
'foo.17.oren.3') will remain the same when I submit the revision to the
owner by doing a sync.
In both scenarios, when I want to _submit_ the patch/revision as a
candidate for becoming the new main line revision, I need connectivity
with one of the dbs people query to ask for the "latest main line
revision". Again, there doesn't necessarily need to be a single,
centralized such db; it could be one of a set of dbs that sync with
each other.
Bottom line is that the only "centralization" is that the branch owner
excersize some minimal common sense when creating new "main line"
revisions on separate, disconnected machines. And even if he doesn't,
the absolute worse that ever happens is that revision ids get
renumbered. I guess you could call that a "centralized failure case".
but to me it seems like a non-issue.
OK, enough rambling. Especially if all the above was already said 6
months ago. Either you find this convincing or you don't. That said, if
the main reason for rejecting "first class forks" is due to Monotone
refusing to allow an "owner" control over his created branch, I may
have to resume looking for a version control system...
Have fun,
Oren Ben-Kiki
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- 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
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux,
Oren Ben-Kiki <=
- 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, Jonathan Matthew, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/11
- 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