Re: [Monotone-devel] Policy branches - first steps

[Timothy Brownawell]

On Tue, 2007-02-20 at 16:26 +0000, Paul Crowley wrote:
>  From the deafening silence, I'm guessing that I might need to make that 
> one a bit more bite-size to get some discussion!
> 
> At the summit, we had some very interesting ideas and proposals for how 
> policy branches could work.  These proposals handled not only policy, 
> but namespaces and branch renaming, IDs for developers, server control 
> and more.  A number of possibilities were put forward.
> 
> However, right now I'm proposing we start by doing the very least we can 
> do to introduce something like policy branches without changing anything 
> else.  We will want more sophistication for a further release, but this 
> will get us started and help us learn about how this stuff plays out in 
> practice, which can be more valuable than any amount of theoretical 
> discussion.  So here's the proposal in brief.
> 
> * A policy branch contains one or more policies
> * A policy lists by name the branches it applies to
> * It can also indicate that it applies to all branches that start with a 
> particular prefix
> * It lists the keys which can commit to that branch
> * or it delegates all decisions about it to another branch
> 
> So: nothing in there to handle branch renames, or to name developers. 

...I don't see how this would be extended to handle branch renaming.

A different idea that's been floating around is to have branch certs be
(project name, random_id), and then the policy branch (probably named
(project, null_id)) contains a {random_id => branch_name} mapping.

> You can't arrange for one branch to have two names because everything is 
> explicit about the name it applies to.  A policy may not introduce 
> ambiguity.  Nothing else in Monotone needs to change to handle the 
> policies, as far as I can tell.
> 
> Does that seem like the right way forward?


-- 
Timothy

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