Re: [Monotone-devel] Re: Re: Re: How will policy branches work?

[Jack Lloyd]

On Wed, Feb 06, 2008 at 10:52:20AM -0500, Zack Weinberg wrote:

> What is the rationale for this requirement?  My knee-jerk reaction is
> that this is ultimately impossible to enforce (untrusted dev A can go
> over to trusted dev B and ask to be shown),

I think the key here is the use of trusted: dev B is trusted to
maintain a set of access controls. Just because he might fail to
uphold that trust does not mean the access control is meaningless (you
could equivalently argue that putting a password on a web application
is meaningless, because someone could always find an exploitable hole
in the httpd and access all the data that way).

Anyone who does have access to the source can delegate that access to
someone else (dev B could give dev A his key, or make a copy of the
workspace for him, or burn the source to a CD and mail it to his
companies competitor). My inclination is that tools should support
that delegation (or lack of delegation).

In a lot of environments, not everyone is allowed to see all the
source.  An example that comes to mind is that a contractor at
Microsoft working on the kernel is not allowed to see, say, the source
for Office (or even other parts of the kernel beyond his immediate
purview). Is it good development process? Perhaps not. Is it something
companies do want pretty regularly? In my experience yes. Is it
something Monotone should support?

So, here is a question. What is the (intended) smallest unit of access
control in Monotone? A file or set of files/certs? A branch? A
project? An entire database containing (potentially) multiple
projects? A server instance serving (potentially, I don't think it's
supported ATM) multiple databases?

-Jack