[Monotone-devel] Re: Re: Using monotone in a team

[Boris]

Daniel Carosone wrote:
> On Thu, Nov 30, 2006 at 12:30:47AM -0000, Boris wrote:
> You're right, of course, such documents could always be extended and
> improved.  Thanks for taking the time to pose your question with such
> an example in detail -- it both gives us something we can work into
> the documentation, and also clearly indicates (by the mistakes you
> make) where the existing documentation hasn't made the concept clear.

No problem! Overall the documentation is good. One of the many reasons why 
I'm interested in monotone is that it looks like it can be setup very 
quickly. Apart from creating a database, a key pair and a workspace there is 
not much else to do to start working - that was well explained in the 
documentation. Where I have some hard time currently is to understand how to 
benefit from certs and how to configure monotone in regard of certs.

> [...]
> You don't so much create a branch as just simply start committing to
> it.  There's no explicit step to create a branch, a branch exists
> simply because there are revs in the db with branch certs containing
> that name.

Ok, understood.

> [...]
> 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?

>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?

> > 3) Let's say he uses the approve command which adds a certificate to the
> > revision. How exactly can this new certificate be used?
>
> approve simply adds another branch cert to an existing revision. This
> could be:
>
>  - a cert for another branch (like above)
>  - a cert for the same branch as the rev already has a cert for, but
>    signed by someone else and therefore likely to be trusted by users
>    differently (ie, a senior developer)
>
>
> > I especially wonder about option #3. Is there some automatic support for
> > approvals or is this something which must be implemented in hook 
> > functions?
>
> It's both.. update (and some other commands) call the trust eval hooks
> to decide whether the revision is considered approved for your
> purposes.  We need some nice concrete examples of this, as you say,

I see. And this is something which must be done in the hook 
get_revision_cert_trust(). And there is even an example in the documentation 
as I just found out. :)

> but I don't have time to put those together right now.  Feel free to
> have a play and post what you come up with.. :)

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

Boris