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

[Boris]

On Tue, 05 Feb 2008 19:30:28 +0200, Zack Weinberg <address@hidden> wrote:

> [...]Because this is a distributed VCS, we can't, ultimately, prevent
> people from doing whatever they want to their own copy of the

It might be possible if policy settings and the list of administrators are  
stored in the database. Even if you have a copy of the database the  
database knows who the admininistrators are and will prevent others from  
changing the policy settings. Of course if administrators change settings  
it takes time for the changed settings to be distributed to all databases  
(so someone might still work on a project even though he was removed from  
it in another database by an administrator). I guess it gets then more  
complicated but I'm not sure if it's entirely impossible? I agree though  
that the current model of everyone can do what he wants with his copy is  
easier to implement.

> [...]The thing we can't prevent, though, is the developer pulling a copy  
> of
> the "documentation" project and modifying its policy to grant
> themselves permission to change it.  And Tim's not currently working
> on preventing the developer from pushing those changes back to the
> documentation team's server.  But, this is less of a problem than it
> might sound, because the developer's modifications - even to the
> policy itself - will be ignored, invisible, to the documentation team.

Yes, no problem for the documentation team: They can ignore these changes.

> [...]Anyone can make themselves administrator in their local database,  
> but
> that change does not propagate to another database.  Changes to
> content branches based on that usurped authority *do* (for now)
> propagate to other databases, but are invisible to the users of those
> databases unless they deliberately go looking for them.  It will be
> possible for other users to sign on to the rebellion (as it were) by
> making the same change to their own local list of administrators; it
> will also be possible for them to pick specific unauthorized revisions
> and approve them, making them visible to everyone.

I see, thanks for the explanation! The problem is that in some (if not  
all) commercial projects there is only one authority. And that authority  
is fixed. There is a more strict hierarchy than in open source projects.  
Personally I would like to use the open source model per project (everyone  
is free to do what they want) but at the same time I need to comply with  
management rules and separate projects.

> [...]?  I confess I don't see the rationale for making project A  
> developers
> unable to even check out project B, especially if A and B are things
> as closely tied as source code and documentation for the same product.

Here's a better example than with source code and documentation: We have a  
software which has to be activated after installation. There are various  
components responsible for activation (a module in the software itself, a  
web service to activate online, a license administrator to manage licenses  
etc.). Management does not want the source code of these components to be  
visible for everyone who uses the monotone database. Imagine for example a  
new co-worker who just joined the project: We do not only trust him to  
make reasonable changes in the activation components (that's something we  
can ignore with monotone) but at least in the beginning we don't trust him  
so much either as if we want to give him read-access to each and every  
part of the software. After all these are management decisions. And if  
management thinks that some files need to be protected and shouldn't be  
visible for everyone we need a way to implement these decisions (no matter  
if they are reasonable or not :).

Boris