[Top][All Lists]

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

[Monotone-devel] Policy branches - first steps

From: Paul Crowley
Subject: [Monotone-devel] Policy branches - first steps
Date: Fri, 16 Feb 2007 19:28:18 +0000
User-agent: Icedove (X11/20061220)

As Graydon points out, we'll learn a lot more about what direction to take policy branches by implementing them than by thinking about them. I propose we make an incremental step that will get us moving, and that we'll be able to build on later.

So here are the corners I want to cut to get something out now. These are all things we'll want to fix in a later revision.

- Use a very simple rule to decide validity - a revision is valid if it's signed by one of the valid keys, no matter what its history. - Don't try and support namespaces or branch renames - use the existing branch names
   (this also means that we'll enforce a tree through the namespace)
- Don't try and use policy to give users names - use existing infrastructure for that (we will want to fix this, but policy branches will be useful before we do)
- Use a dumb implementation of ACLs

I've checked in some sample policy branches. I haven't used the names these branches would have in a real implementation, though.

- should really be called "address@hidden" or another user name
- This might be a user's personal policy branch. It delegates all authority on all Monotone branches to
"net.venge.monotone-policy.founder" as signed by Graydon.

- should really be called "net.venge.monotone-policy.founder"
- Delegates authority to "net.venge.monotone-policy.main" as signed by Graydon or Nathaniel

- should really be called "net.venge.monotone-policy.main"
- has a big list of keys which are allowed to commit to any Monotone branch. I got this list by running "mtn automate keys" over my local Monotone database.

The file format is designed to be extensible, to minimize the need for backward incompatible changes. I'll go through an example now.


Each policy can contain a human-readable README file.

 * ./version_1

The rest of the policy lives under this directory. This gives us the freedom to add new names at the top level without worrying about collisions

 * ./version_1/monotone

This is a policy. The name is arbitrary - you can call a policy anything you like, the system ignores it. A policy branch can contain more than one policy

 * ./version_1/monotone/branches

A directory that lists the branch names the policy refers to

 * ./version_1/monotone/branches/net.venge.monotone

As far as I know a branch name can contain any character, so rather than using a filename to reference them we use the contents of a file. For clarity this file has the same name as content, but you can call the file anything, the system doesn't care. If you want to reference two branches, create two files.

 * ./version_1/monotone/branch_prefixes

This is similar to branches, but it states that the policy applies to all branches that have a particular prefix. No branch_prefix in a policy may be a prefix of any branch_prefix or branch anywhere else in that policy branch.

 * ./version_1/monotone/branch_prefixes/net.venge.monotone.

Again, it is the contents of the file that specify the prefix rather than the name. Note that this policy does not apply to, for example, net.venge.monotone-viz. Because net.venge.monotone-viz is a prefix of net.venge.monotone, we have to support both naming explicit branches and naming prefixes, and we have to let the same policy apply to both.

 * ./version_1/monotone/defer_to

States which policy branch this policy defers all decisions to. This must be a branch for which policy is specified elsewhere in the policy branch, as in the examples.

defer_to is present in, for example, the founder branch. In the main branch we have something different:

 * version_1/monotone/head

sets direct conditions that revisions must meet in order to be considered part of the "head" of monotone. The idea is that we can later add, for example, conditions on the ancestry.

 * version_1/monotone/head/any_of

In order to be considered part of the head, it must be signed by any of the keys in this directory

 * version_1/monotone/head/any_of/475b5e52f544b996f657c143b897287b87b61978

The file contains a key fingerprint. Again, the name of the file is arbitrary; for convenience it has the same name as content.

ACLs: I imagine that for a first pass, the user will simply specify the name and keys for their personal policy branch in their .monotonerc. Again, we can think about greater sophistication later.

This is all of course highly provisional. It's only a proposal. However, hopefully a fully-worked proposal on how we can move things forward will help.
\/ o\ Paul Crowley, address@hidden

reply via email to

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