[Top][All Lists]

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

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

From: Boris
Subject: [Monotone-devel] Re: Re: How will policy branches work?
Date: Wed, 06 Feb 2008 12:30:19 +0200
User-agent: Opera Mail/9.22 (Win32)

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


reply via email to

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