monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction


From: Daniel Carosone
Subject: Re: [Monotone-devel] Re: [RFC] versioned policy -- introduction
Date: Fri, 8 Sep 2006 10:16:38 +1000
User-agent: Mutt/1.5.13 (2006-08-11)

On Thu, Sep 07, 2006 at 01:18:20PM -0700, Graydon Hoare wrote:
> The point of this work is not to change the trust model of monotone. You 
> still have final say on what happens with your computer, bob still has 
> final say on what happens with his computer.
> 
> The point is to make it easier to do three things:
> 
>   - Write trust policies (both update-trust and netsync-trust)
> 
>   - Share trust policies across a workgroup automatically
> 
>   - Learn about the policy in force across a workgroup such that
>     you don't personally commit policy-violating work that will
>     only be rejected by everyone else.

If an analogy or example helps illustrate the concept, consider the
following hypothetical example:

 - each user is asked to include from their monotonerc a lua file from
   within the workspace.  (the trust seed)

 - the project states its policy by writing trust hooks, just like
   now, in this lua file published within the project.

 - users end up using those trust hooks, effective as they were at the
   time of the current revision, unless they've added some further
   overrides of their own.

Now, obviously, there are loads of potential problems with such an
implementation.  The goal here is to come up with a better way to
allow trust delegation.  

Consider the next-simplest possible implementation, where default
trust hooks look at specifically-formatted dotfiles in the workspace
for various kinds of trust policy, like the ignore hook presently
looks at .mtn-ignore.  Still there are plenty of problems with this,
but it starts to show the general direction of the idea; it's not so
much about changing the fundamental trust model as it is about adding
some management conventions/structure/mechanism around it.

Along the way, we also need/want to address some issues and
opportunities in related areas, many of them to do with naming, that
will help both the policy management piece and other general usage
issues (like branch renaming).

--
Dan.

Attachment: pgpT3YhBP7cPQ.pgp
Description: PGP signature


reply via email to

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