On Thu, Nov 30, 2006 at 12:20:06PM -0000, Boris wrote:
> > Question: There is no way (and I assume no need) to set write-permissions
> > per user? I don't see anything in the documentation that I can use pattern
> > and allow in write-permissions, too?
> >
> > you can set write (ie, send to me) netsync perrmissions per user - but
> > you can't set them per branch. This relates to the fact that revs can
> > be on multiple branches, and the revs come through first before we
> > know which branch they're on.. sometimes *months* before, because a
> > rev can be approved onto the branch later.
>
> I see. To put it in my own words: Every user with write-permission can
> commit any code to any branch (as ideally his code is used one day - that's
> why he has write-permission after all). It depends however on the certs if
> his code appears in a developer's workspace directly or only after
> approvals. Is this correct?
Yes, almost. There's still a very fine distinction here it's worth
elaborating on, even if it's just a matter of overly-precise
terminology. There's a step in the middle you missed or glossed over,
and it makes all the difference between the different kinds of things
you're calling permissions. There are three distinct permissions
mechanisms at work here. Let's have a go at rewriting your description
accordingly:
Every user with write permission to their own local database can
commit any code to any branch. If they also have write-permission to
one or more netsync servers they can send their revs (and certs) to
those servers, publishing them in the hope they'll be used one day
by someone else. When someone else considers whether to use those
revisions, they use the certs on the revision to evaluate whether
the revision is suitable to appear in their workspace.
The first kind of permission is local filesystem permissions on your
own db file. We assume everyone has that and don't really talk about
it, but it is important when you're considering "permission to
commit". Everyone can commit
The second kind of permission is the netsync permissions hooks (the
read- and write-permissions text files). These are a fairly blunt
instrument, for basic access control to the netsync server:
"permission to copy" and "permission to send" new revisions. Note
that regardless of the coarseness of the write permissions, they
aren't "permission to publish" because the user can always choose to
publish their revs on their own netsync server. Others can take them
from there and pass them on (like Abe and Beth did in the tutorial).
The third kind of permissions are on entry to the workspace (and some
other similar purposes, such as being considered a suitable merge
candidate). These are much more fine-grained, and we generally refer
to them as 'trusts' or 'trust settings' rather than as permissions.
These are the ones that really matter in monotone, and that are really
quite different to most other systems (which often try to achieve this
kind of control at one of the earlier stages).
This has lots of advantages. Evaluating trusts later rather than
permissions earlier allows things to happen in stages. Additional
information (certs) can accumulate over time as other developers
review code, or as automated test suites run, which might change trust
evaluation decisions. Developers can also change their trust criteria
and reevaluate the existing information with different results.
> From a design point of view I think I also understand that I don't need and
> want to control branches. What I want to control are the permissions based
> on trust as it depends on them what code ends up in my workspace, right?
Spot on.
Even more important example: You can have different workspaces with
different approval criteria configured in the workspace-local
_MTN/monotonerc file - perhaps one workspace for the "blessed"
revisions, and another with lower requirements where the junior
developers' revs are allowed in so they can be reviewed and approved.
Both of these workspaces can share the same db.
> Thanks, your explanations have been very helpful! One of my
> misunderstandings was that the hook functions looked like they are only used
> by advanced users or for some extensions. I assumed that I have to find a
> configuration file or use some monotone commands to configure the trust
> mechanism. I think I understand now that hook functions are actually the
> successor of the good old static configuration files. :)
Spot on, once again. Welcome to monotone's world, I think you'll fit
in just fine. :)
And again, a more specific example to make the purpose of this choice
very clear: you've found the netsync read- and write-permissions
files, and perhaps also the .mtn-ignore file, all of which look like
the old-style static configuration files. Look a little closer, and
you will discover that these files are not actually configuration
files for monotone proper. They are in fact read by the default
implementation of the relevant Lua hooks, provided as a convenience
for users who just want to specify simple lists of things to allow,
ignore, etc. You can override these default hooks completely, and
replace them with something that only allows Fred to read revisions
via netsync on tuesdays and every third friday unless its also a
public holiday, if you like. Monotone itself just calls the hook and
looks at the result.
--
Dan.
_______________________________________________
Monotone-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/monotone-devel