Re: [Monotone-devel] Meta-policy proposal

[Timothy Brownawell]

On Mon, 2006-09-11 at 17:23 -0700, Zack Weinberg wrote:
> 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.

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.

> 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.

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.

> 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?

Tim
-- 
Free (experimental) public monotone hosting: http://mtn-host.prjek.net