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

[Markus Schiltknecht]

Hello Boris,

Boris wrote:
> 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

Who are 'the administrators' in a distributed setting? I know, this 
might be very clear in a hierarchically organized company. However, for 
lots of open source projects, I would consider every single developer as 
the admin of his repository.

I'd rather speak of a project leader, which "dictates" a project wide 
policy. However, we were discussing about how to handle switching 
leaders, where a project suddenly gets a new leader and the policy 
authority changes...

> 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.

Yes, it can get pretty complicated. However, we (uh.. mainly Timothy) 
want to give it a try. Let's wait for another iteration, until we get 
the user interface straight and comprehensible enough.

> 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.

Hm.. maybe use the netsync hooks to delete untrusted revisions 
immediately on the central repository?

Also check out the work of Ralf S. Engelschall, he did some tweaking to 
the netsync hooks, to be able to deny untrusted certs immediately.

> > [...]?  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 :).

If the files for these activation components are in the same branch, 
each revision maintains a hash over their contents. So, if the new 
co-worker is denied downloading those files, he cannot completely 
validate the revision. That would clearly speak for splitting those 
files into its own projects.

OTOH, that new co-worker cannot change these files, so monotone could 
simply skip the hash calculation for those files and reuse the existing 
hashes from the parent revision. I'm slowly beginning to think, that 
what you want here, is policy branches in conjunction with partial 
checkouts (where these activation component files are missing).

Regards

Markus