[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Schiltknecht
Subject: Re: [Monotone-devel] Re: Re: How will policy branches work?
Date: Wed, 06 Feb 2008 13:51:27 +0100
User-agent: Mozilla-Thunderbird (X11/20080110)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]