[Monotone-devel] Re: Policy branches - first steps

[Bruce Stephens]

Paul Crowley <address@hidden> writes:

[...]

> However, right now I'm proposing we start by doing the very least we
> can do to introduce something like policy branches without changing
> anything else.  We will want more sophistication for a further
> release, but this will get us started and help us learn about how this
> stuff plays out in practice, which can be more valuable than any
> amount of theoretical discussion.  So here's the proposal in brief.
>
> * A policy branch contains one or more policies
> * A policy lists by name the branches it applies to
> * It can also indicate that it applies to all branches that start with
> a particular prefix
> * It lists the keys which can commit to that branch
> * or it delegates all decisions about it to another branch
>
> So: nothing in there to handle branch renames, or to name
> developers. You can't arrange for one branch to have two names because
> everything is explicit about the name it applies to.  A policy may not
> introduce ambiguity.  Nothing else in Monotone needs to change to
> handle the policies, as far as I can tell.

OK.  What about forks and merges?

I'm imagining the following kind of situation: I'm developing (in my
local database) some branch under net.venge.monotone, and in order to
conveniently do that, I commit my own policy revision.

And then (as the upstream policy is updated) I end up repeatedly
merging the policy branch---much as I end up propagating changes from
net.venge.monotone to my content branch.

Or maybe that's a special case, and I just always have arbitrary
permissions on my local database?  In which case that still leaves the
general problem of divergence, but maybe we could live with that,
since (presumably) the branch would almost always automatically merge,
so monotone could just refuse to use an unmerged policy branch?  (Oh,
with some magic to permit the root policy branch to be merged, I
guess?)

[...]