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

[Oren Ben-Kiki]

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