monotone-devel
[Top][All Lists]
Advanced

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

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


From: Zack Weinberg
Subject: Re: [Monotone-devel] Re: How will policy branches work?
Date: Tue, 5 Feb 2008 12:30:28 -0500

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 <address@hidden> 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




reply via email to

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