Re: [Monotone-devel] Meta-policy proposal

[Zack Weinberg]

On 9/11/06, Timothy Brownawell <address@hidden> wrote:
> ...what happens if someone makes a parentless commit with that branch
> name but a different policy branch, then merges that in with
> merge_into_dir?

Any time you merge, the policy of the branch you're merging *into*
applies.  Again, it has to be that way or you break the security
model.

> > 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.)
>
> Ah. See, I was thinking it would be one policy branch per project. So
> the project gets a branch namespace, which is then attached to the db's
> branch namespace either by the suggested prefix (given in the policy
> branch) or by a config file (much like mount and filesystems...).
>
> You seem to be saying multiple policy branches per project, and only one
> project per db (or at least, no *hostile* projects sharing a db)?

Hm, not quite ... All I'm saying is that you shouldn't have to tell
"mtn ls branches" which namespace you're in.  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.  For instance, one
could have botan.* next to monotone.*, and have different policy
branches for both.  Two rival development teams for the same project
can do the same, again as long as there's enough civility that they
can agree on a partition (netbsd.*, openbsd.*)  Only when they can't
get that agreement is it necessary to have multiple databases.

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.

It is also the case that a project can have multiple policy branches
if it wants to have multiple classes of developers, but that's
orthogonal.

zw