Re: [Monotone-devel] Meta-policy proposal

[Timothy Brownawell]

On Sun, 2006-09-10 at 23:53 -0700, Zack Weinberg wrote:

> Otherwise the cert must declare
> the same policy branch as its parent revision's branch cert.  (For
> merges, it only has to agree with the parent with the same name.)

Why? What if I *want* to have the same branch name under a different
policy, such as because I'm forking?

> When you create a new branch from a given revision, the policy for
> that branch is normally the policy of the parent rev's branch.
> However, if the parent rev's policy doesn't include your key, you have
> to specify a policy that does include your key (either on the command
> line, or in lua hooks, to save typing).  At that point the *other*
> thing in each policy branch kicks in: a restriction of some sort (a
> list of globs, perhaps?) on the branch names that are allowed to be
> generated using that policy.  These two things together give us a
> full-fledged branch-based permissions mechanism.

I'd think rather that it'd be a list of branch globs for each key,
saying who could commit where. 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...).

> Now, we also need rules for dealing with conflicting updates to a
> given policy branch.  I propose a very simple rule: Netsync refuses to
> create divergence in a policy branch, except if being run in
> "sink_role" (i.e. "pull").  And if it is run as "pull", and divergence
> is generated, you are *immediately* required to merge heads.  This
> will never inconvenience a user who doesn't touch policy branches,
> unless they try to pull from two databases with conflicting policy
> branches with the same name (i.e. both sides of a totally hostile
> fork) -- anyone doing that can probaly be assumed to know what they
> are doing.  It may be a minor inconvenience for admins -- suppose
> Alice adds Carol to the main policy branch, and Bob adds Dave at the
> same time; one of them will get their sync rejected and have to pull,
> merge, push.  However, this would be a concern no matter what.

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.

Tim