monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Re: Re: Re: How will policy branches work?
Date: Wed, 06 Feb 2008 18:50:25 -0600

On Wed, 2008-02-06 at 11:33 -0500, Jack Lloyd wrote:
> 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?

Access control is "branch + ancestry", and should probably stay this
way.

This can be equivalent to "revision + ancestry" if you use enough
different branches.

When we get a proper method of composing revisions (which we really
need, since merge_into_dir doesn't allow you to send changes back
upstream), it will be about the same as "branch/revision subtree +
ancestry".

If we get partial-pull support, the "+ ancestry" could *maybe* go away.
But since this would prevent some things from being validated, we might
not want to do this.


-- 
Timothy

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]