Re: [Monotone-devel] Meta-policy proposal

[Zack Weinberg]

On 9/11/06, Timothy Brownawell <address@hidden> wrote:
> On Sun, 2006-09-10 at 23:53 -0700, Zack Weinberg wrote:
> What if I *want* to have the same branch name under a different
> policy, such as because I'm forking?

I think that the property - that you can only change the policy branch
for a given branch if you could change the policy branch itself - is
necessary to make the security model work.  The intent is to force
someone who forks to create either their own (content) branches for
the fork, or their own netsync server.

> I'd think rather that it'd be a list of branch globs for each key,
> saying who could commit where.

That seems redundant with the existence of multiple named policy
branches.  Policy A says that keys K, L, and M can commit; policy B
says that keys N, O, and P can commit; you apply A and B to the
appropriate sets of branches, and you get the same effect.

> Then the policy branch would also
> set a prefix, to distinguish identically-named branches under different
> policies (there'd have to be a way to override this, in case you wanted
> to use two projects that had their prifixes set to the same thing...).

In my scheme, you cannot have identically named branches under
different policies on the same netsync server, and I think this is a
feature.  (Really, best practices are for branch names to be globally
unique - hence "net.venge.monotone.whatever" instead of just
"whatever" - but we can't enforce that.)

> What if you have multiple netsync servers for your project, synced with
> eachother at some interval? Alice changes policy and syncs with one
> server, Bob also changes policy and syncs with the other server. Neither
> of them notices immediately because they do this between the sync
> interval that the two servers are set to.

Oh, ugh, I hadn't thought of that.

Perhaps it would be a good idea to maximize the number of cases where
policy-branch changes can be merged without human intervention, and to
make the rule be that on any netsync, it auto-merges, only rejecting
the transaction if the merge can't happen.  (This is another argument
for the simple "a policy is a set of keys" arrangement.)  But we won't
be able to get them all, which means your scenario is still live.
Also, I was relying on "you can't push a conflicting policy without
renaming it" in the security model...

Don't have a good solution to this one.

zw