Re: [Monotone-devel] Meta-policy proposal

[Zack Weinberg]

On 9/11/06, Timothy Brownawell <address@hidden> wrote:
> > Hm, not quite ... All I'm saying is that you shouldn't have to tell
> > "mtn ls branches" which namespace you're in.
>
> I don't see how what I'm suggesting would require that. The policy
> branch for one project says, all branches claiming this policy get
> "foo." prepended to their names, and the policy for another project uses
> "bar.". so "ls branches" would show "foo.main", "foo.devel", "bar.main",
> "bar.release", etc. The config file would only have to come in if two
> (presumably hostile) projects tried to claim the same prefix.

Oh.  I thought you were saying that for each policy branch, there was
an entirely separate namespace, so "main" (policy="foo") and "main"
(policy="bar") were different branches.  That's what I don't like.
Your suggestion seems reasonable, except it might not be flexible
enough - what if I want to express policy of the form "developer X can
commit to these four branches with no relationship among their names"?

> > Two projects can have
> > separate policy branches and share the same database as long as they
> > can agree on a partition of the branch namespace.
[...]
> See, I think that isn't good that they'd have to agree in order for
> things to work. It means that if someone suddenly decides they *don't*
> agree, they can break things.

I don't see how you can avoid the need to come to an agreement except
by the separate namespaces for different policy branches thing, or by
separate databases entirely.

In my scheme, though (assuming we think of a solution for the delayed
discovery of divergence problem) it's not possible for someone to
break things if they suddenly decide they don't agree, because they
can only set up their own little sandbox in a corner (i.e. their own
set of policy and content branches, possibly forked from the rest of
the project); they can't interfere with the existing policies.  Unless
they're an admin, but then you have bigger problems.

> > It might, in this context, be useful to have a mechanism whereby all
> > the branches in database A get a prefix applied to their names when
> > syncing with database B (so A->a.b.c == B->foo.a.b.c) -- very much
> > like unix filesystem mounts -- but I would hold off on implementing
> > such a feature until there's user demand.
>
> How would this work, with branch certs being signed and all?

Um ... not sure.  Some clever arrangement where what's signed is just
the "a.b.c" part and the "foo" part is local configuration.

zw