Before I get into specific concerns of yours, I want to say up front that this list talks about "policy branches" as if it were one thing, but it's not; it's a whole cluster of features. We ultimately want to support all of them, but we're not going to do all of them at once.
If I understand your scenario correctly, everything you want corresponds to a feature in the cluster, but some of them are going to be implemented later rather than sooner. However, you may find, once we have the initial subset of the features done, that they are actually sufficient to your purposes; this is what Tim is trying to say, I think. On Tue, Feb 5, 2008 at 10:49 AM, Boris <[EMAIL PROTECTED]> wrote: > > Let's say a developer changes something in "sourcecode" and commits the > change to "documentation" (either accidentally or intentionally). As the > documentation team has access to this branch it would start to see files > they really shouldn't see? Because this is a distributed VCS, we can't, ultimately, prevent people from doing whatever they want to their own copy of the repository. But this turns out to be not as much of a limitation as it might sound. We can prevent accidents, by arranging that *by default* the developer doesn't pull the documentation. This capability exists right now, in the form of the branch inclusion and exclusion patterns for the netsync commands. We can make that have more teeth, by defining policies that will let the developer deliberately pull the documentation (maybe they want to read it, ya?) but not commit to it. I'm not 100% sure but I think this is part of what Tim is working on right now. 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, 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 the project definition file is a local file I don't understand why it > contains a list of administrators. I must misunderstand as it sounds as if > everyone can make himself administrator by changing his project definition > file? 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. > You are right. I need to clarify my requirements: I need to define > projects and assign people to them. People can do whatever they want in > their projects. However they must not get the files in the other projects > (which means they either aren't transferred or they are transferred but > can not be checked out - if that is safe at all). That again means it > shouldn't be possible for people to simply assign themselves to other > projects. Is it enough for you if people in project A: * do not by default pull project B * if they do deliberately pull project B, they can check it out * by default, those checkouts are read-only, but can be forced writable * if they do deliberately force a commit to project B, nobody in project B will notice unless they go looking for it ? 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. zw _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
