[Monotone-devel] branch representation

[Nathaniel Smith]

So, err, here's a stupid idea that popped into my head, reading the
recent discussion of 'disapprove'.  I want it to be clear that this is
not a "here's something I've been thinking about for 3 months and
it's going to solve 5 problems you hate and 5 you never even knew you
had" kind of message, this is a "hrm, this is a crazy idea and I can't
even tell whether it's crazy enough to be right or not" kind of
message...

So the idea is: what if we got rid of branch certs, and put a branch
field inside the revision object?  So each revision is uniquely,
irrevocably, in a single branch.  So each revision is not just a
snapshot, but a snapshot with a purpose attached.  And instead of
automatically putting a branch cert on at commit time, you put a
"yeah, this is good" cert on (since the rev already has a purpose
built in, your vague affirmation of goodness can be assumed to match
that).

Yeah, this is a really weird idea.  It's weird enough that I have
trouble really imagining it to evaluate it.  (And enough that I
deserve to be hit repeatedly with a stick for bringing it up when
we're trying to _stabilize_ things...)

Anyway, this wouldn't help with things that people find
counter-intuitive like, "this branch is discontinuous", or "this
branch has multiple branch points", or "this branch has multiple
heads".  It would help with the confusion about revs being in multiple
branches, and generally reduce the weirdness we have all the time
where we have to assume all revs have branch certs on them, and try
and guess an appropriate branch name given a revision, and so on -- it
seems like the code and users both want to think of branch certs as at
least somewhat special.  I'm thinking of guess_branch, and update's
tricky handling of branches, and netsync filtering by branch...

It might make doing trust stuff significantly easier.  I _think_ a
design criterion for a trust system is that I want to be able to
specify rules for trusting certs that aren't branch certs, and I want
to do this per-branch.  This seems very tricky, if the rule for
deciding whether you trust a 'foo' cert begins "collect all branch
certs on the same rev, invoke the branch trust rules on them, for
each branch cert that turns out to be trusted, find that branch's
trust rules for 'foo' certs, and then somehow combine the results of
applying each branch's rules".  And there are probably horrible
convoluted attacks:
  Alice has tag and branch cert rights to branch A.
  Bob has tag and branch cert rights to branch B.
  Alice wants to check out the tag 'A-release' so she can send it to
    the CD manufacturers.
  Bob does good work over on his project, so Alice does trust him to
    tag revs on branch B, but he happens to hate project A.
  Bob takes a buggy rev R on branch A, and adds two certs to it:
    branch: B
    tag: A-release
Now rev R is, according to the trust rules, quite definitely in both A
and B.  The A-release tag on it is trusted with respect to branch B's
rules, but not respected with respect to branch A's rules.  So... do
we trust the A-release tag, or what?  I guess the unavoidable
conclusion is that you can't determine cert trust based on just the
contents of the DB plus the current trust rules, but also need to know
something about the current context?  (checkout -b B -r t:A-release
should work, checkout -b A -r t:A-release should silently ignore it?)
This seems bad.  Maybe I'm missing something.

(Okay, maybe trust issues _have_ been stewing around in the back of my
head for more than 3 months.  But I don't really understand them, so
it's maybe premature to use them as arguments in a discussion...)

This idea does add a significant new piece to the model -- instead of
the nice clean DAG of snapshots _here_, and generic metadata mechanism
_there_ setup, we have a piece of magic metadata, that needs to be
handled differently, etc.

Umm.  Probably lots of other things to say, too, but I'll stop here
for now :-).

-- Nathaniel

-- 
"Of course, the entire effort is to put oneself
 Outside the ordinary range
 Of what are called statistics."
  -- Stephan Spender