Re: [Monotone-devel] Meta-policy proposal

[Rob Schoening]

Does monotone have a concept of a "project"?  I didn't think it did, other than by convention. 

 

I'm not necessarily saying that it should, but since a lot of this use-case discussion revolves around authorization issues in the lifecycle of a project, it does beg the question somewhat.

 

Tim, how do you partition "projects" today in your multi-tenet setup?

 

RS
 

On 9/11/06, Timothy Brownawell <address@hidden> wrote:

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

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

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

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

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



_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel