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

[Justin Patrin]

On 9/7/06, Bruce Stephens <address@hidden> wrote:
> Nathaniel Smith <address@hidden> writes:
>
> [...]
>
> >   * We need some way to manage "commit" permissions.  For now, people
> >     have been faking this functionality using netsync permissions,
> >     but this approach is deeply unsatisfactory.  A major design goal
> >     of monotone is to make communication as noncommittal as possible;
> >     to make it so you can always, painlessly and without worry, send
> >     information around.  Not only that, but netsync permissions don't
> >     really work right for this anyway; we have all these lovely
> >     signatures and audit trail stuff, and it's completely orthogonal
> >     to the netsync permission system that everyone uses in practice.
> >     -- Solution?: create some kind of local, per-project ACL list,
> >        which is modifiable by some users (controlled by the ACLs),
> >        which everyone locally uses to decide which certs they believe
> >        in.
>
> But it's my database, so surely I get to decide which ACL list forms
> my trust seed, so if I decide I want to commit, then I can make that
> possible.
>
> More than that: that's an important feature, not a bug.  I shouldn't
> be prevented from committing to a tree just because its owners haven't
> (currently) allowed me to.
>
> So is there something you aren't describing, to do with how all this
> gets enforced?

It seemed like this would be something that you can alter in your
local database. You can commit a revision to your local trust branch
to allow you to commit to whatever you want, then happily do whatever.
When you push the server would look at its trust branch before
allowing your revisions to be sent/saved. This would include your
trust revision so its policy branch would stay as-is and not allow you
to push your revisions to their branch.

--
Justin Patrin