Re: [Monotone-devel] How will policy branches work?

[Timothy Brownawell]

On Tue, 2008-02-05 at 13:45 +0200, Boris wrote:
> Can anyone explain to me how policy branches will work when they are added  
> to monotone one day (from a user perspective)? I ask as in the commercial  
> projects I'm involved in more and more files will have to be added to a  
> version control system. So far the projects I've been responsible for have  
> been using monotone. As not only source code will have to be maintained in  
> monotone in the future I need more fine-grained control over who may use  
> what. I've seen policy branches mentioned from time to time here on the  
> list but don't really know how they will work.

Anyone can write anything to any branch. The idea of policy branches is
to know who to ignore. Say you want to have a list of people who can
commit to a branch, but instead of trying to stop people not on the list
from committing (since that doesn't work so well in a distributed
system) you ignore any commits by anyone who isn't on the list. A policy
branch is just a branch that has lists like this for other branches.

In the terminology I'm using at the moment, a 'project' is defined by a
file that users put in their configuration directory, which defines a
policy branch and who can commit to it (without being ignored).

> Coming from the requirements side I think I would need something like  
> this: I create a monotone database and make someone (like myself)  
> administrator. The administrator can then set read-/write-permissions for  
> branches. For example I could allow developers to use the branch  
> "sourcecode" while the documentation team will use the branch  
> "documentation".

You can set up policy branches, and define a project using them for
yourself. You'll have to get everyone else to define the same project,
but I'm sure that won't be too hard to do (particularly since they'll
need *some* project defined, in order to have readable branch names).

Policies can be tied in to the netsync read permissions, and maybe write
permissions, but that's not particularly high on my todo list.

>  Once a file is checked into the branch "sourcecode" it  
> must remain in this branch.

Not sure what you mean here.

>  The settings would be stored in the database  
> and can not be changed by anyone except the administrator(s).

Yes, but remember that the list of administrators is in the project
definition file. So it's fairly easy for someone to change who they
consider to be administrators.

>  If now a  
> developer and someone from the documentation team synchronize their  
> databases the developer would not get the "documentation" branch and the  
> other one not the "sourcecode" branch. Other branches with read/write  
> access for everyone would be transferred.

Not going to happen for a while, if at all. This would require...
 * The client would have to check permissions, instead of just using
   what is specified on the command line. Any central server would
   then need to be granted read permissions for everything.
 * The server and client would have to negotiate a list of allowed
   branches to sync. Currently, it just errors out if you try to
   pull a branch you don't have read permissions for.

> I don't know if policy branches in monotone will work like this and if my  
> idea makes actually sense (maybe there are some problems I'm not aware  
> of). The basic idea is that I want to continue to benefit from a  
> distributed version control system while I need more control over who will  
> get and use what. I understand that I can not prevent team members from  
> distributing files in another way. However I would prefer if files are not  
> spread to everyone automatically or accidently by the version control  
> system.

We don't care very much at all about who can write things, because
that's not really enforceable in a distributed system. Instead we
concentrate on ignoring things we don't like.

We do have some support for preventing people from seeing things, but it
assumes that people don't talk directly to other people who have things
they aren't allowed to see. This can be changed, but it would be a
fairly significant change that most of us probably don't particularly
care about (if secrecy is that important, just put firewalls between
everyone).


-- 
Timothy

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