Random notes on how to version policy (fine-grained permissions, trust delegation, branch names...).

Mostly-obsolete notes of historical interest

January 2007:

http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9835/focus=9835

http://thread.gmane.org/gmane.comp.version-control.monotone.devel/9842/focus=9842

And one from Paul Crowley (February 2007):

http://thread.gmane.org/gmane.comp.version-control.monotone.devel/10077/focus=10077

Useful conversation from April 2006:

http://colabti.org/irclogger//irclogger_log/monotone?date=2006-04-18,Tue&sel=119#l194

Includes argument for why the right rule for evaluating whether a merge followed permission rules, is if either cset is allowable by permission rules.

The pastebin link (since it will probably expire) is to this text:

branches/
  monotone/
    id: file containing a single hex nonce
    status, description, ...: can drop arbitrary other files in here, if useful
    release/
      1.0/
        id
      1.1/
        id
    old/
      win32/
        id
      changesets/
        id

This is file layout for a project with 5 branches, with names:
  monotone
  monotone/release/1.0
  monotone/release/1.1
  monotone/old/win32
  monotone/old/changesets
The ideas is that the branch hierarchy is directly represented
in the filesystem hierarchy; every directory under 'branches'
corresponds to a branch iff it contains a file named "id".  This
is a super obvious representation (everyone already groks the
filesystem), gives full rename support for branches, lets you
stick other ancillary information in where you want (extra info
on each branch, maybe have a README file inside monotone/release/
describing release policy, even though that dir is not itself a
branch), lets you have both "foo" and "foo/bar" as branches.

Details are not important, instead of having a file named "id"
it could be an attr on the directory, or whatever makes sense,
I don't care at this point.

Some minor changes

Make the "id" file into an attribute on the directory; then you can get at it only reading the roster, and users are less likely to even pay attention to it / know it exists, so less likely to be tempted to fiddle with it.
Other attributes you could add to the directory (branch):
"active": when true, the branch is considered active. When false and the branch has no childless heads, the UI can safely omit it from things like "ls branches".
"parent": designates another branch as a logical parent, can be used as a hint to the UI so that the parent's owner can see which sub-branches have changes awaiting integration.
some sort of "pointer" entry -- e.g., instead of having an "id", have a "seed", which gives the trust seed for another project. Then we can refer to branches of that project as /. (Maybe also their keys, tags, etc.?) This is SPKI-style friend-of-friend naming.

Further suggestions

Make a "users/" directory which stores a file for each user.
Permits a project to assign "short names" (a la unix logins) rather than having to use email addresses
Permits associating changing email addresses, and multiple forms of contact info, with a user
Permits storing per-user hooks and preferences; monotone can know which user you think you are and can load your defaults from there
Make a "keys/" directory which stores public keys.
"keys/" stores the public key material for ""
Make a "keys/revoked" directory which a key is authorized to move itself into, but nobody is authorized to move it out of.
Make a "policy/" directory which stores declarative ACLs.
"policy/root" stores the root policy file for the policy branch, cannot be moved or deleted.
"policy/*" stores other policy files, access to which is granted, by delegation, from rules in "policy/root"
Make a "servers/" directory which stores server configuration.
"servers/<public-dns-name>:" contains configuration for that server.
Store read/write access rules, set of branches served.
Store list of other servers and branches to automatically sync with (at some frequency).
Only describing server's relationship with this project; server can host many projects.
1-1 mapping from db to trust seed? Seems like a collapsing that we can get away with, and feels like things click in nicely if we do it, at least to me.

User requests

http://article.gmane.org/gmane.comp.version-control.monotone.devel/6917

Questions

Correct me if I'm interpreting this idea incorrectly. You plan on using a directory hierarchy of configuration files to describe policy concerning branches in the repository database itself; that these directories are not working directories for your branches. Where would this directory hierarchy exist? As another branch in the database? Would you use a special checkout command to get it (mtn -d DATABASE -bBRANCHNAME co --policy PDIR), or simply specify something like -bBRANCHNAME."policy". Could you provide links or information on the "big picture." -- ChadWalstrom

You plan on using a directory hierarchy...to describe policy...these branches are not working directories for your branches -- yes, exactly right. As another branch in the database?* -- yep again, probably with some fixed name, I guess? The exact UI beyond that I'm not sure -- certainly one thing to figure out as things settle down would be what sort of sugar is useful. I'd almost be tempted to have it automatically checked out to a subdirectory of _MTN/ or something, even, just to make things as low-impedence as possible? But this is just guessing, can't make sensible UI choices until much later in the process. -- NathanielSmith

Basic requirements

Way to track "which project are we on" (db var?)
- Need some way to get this set when we do initial pull
Place to set branch names
- branch names supported in UI
- can add new branches, manipulate existing branches
Place to store keys
- keys have names
- can add new keys, rename existing keys

Incrementality

What's the minimal thing that "does something"?

Possibly a way to manually set a branch as a metadata branch, via a db var, and then add things like branch name remappings on top of that?