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

[Daniel Carosone]

On Thu, Nov 30, 2006 at 12:30:47AM -0000, Boris wrote:
> I read TrustFoundations in the Wiki. And while I think I understand what it 
> talks about I agree it's a bit theoretical. Maybe someone can tell me what I 
> actually need to enter on the command line when we look at an example:

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.

My apologies, I'll have to respond to the rest of your question very
briefly now, for lack of time, but I or others can follow up later to
further questions.

> Jim's company has been growing due to the success of JuiceBot. More 
> developers joined his team to work on new versions of JuiceBot. The flat 
> hierarchy in the earlier days of the company changed: Now there are junior 
> and senior developers. While he doesn't mind senior developers to mess 
> around in the code he doesn't want junior developers to change code in the 
> main branch. He wants changes of junior developers to be approved by senior 
> developers.
> 
> Jim creates a new branch for junior developers:
> mtn --branch=jp.co.juicebot.jb7.junior --message="junior branch"

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.

> Then he changes the file read-permissions to:
> pattern "jp.co.juicebot.jb7*"
> allow "address@hidden"
> pattern "jp.co.juicebot.jb7.junior*"
> allow "address@hidden"

Nah, you don't want these permissions, they're for netsync not for commit.

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

> Now junior developers work on their own branch while senior developers can 
> change code in the main branch directly. From time to time a senior 
> developer checks the junior branch.

Again, it's not about permissions to change things, it's about whether
your trust (ie, how you pay attention to) what they do.

In this context, this means that everyone accepts changes in the
junior branch from junior and denior developers, and in the main
branch only from the senior developers.  More specifically, that I
only trust main-branch certs signed by senior developers.

From time to time, a senior developer looks at revs in the junior branch.

> 1) Let's say everything is all right. He can then propagate changes from the 
> junior to the main branch and vice versa?

Yes, he can propagate from the junior to the main branch (which is a
merge of the two heads, putting the result on the main branch), or he
can approve the junior rev also onto the main branch and then merge
that.

A junior developer can do this too, but his revisions won't be trusted
for update by someone else with trust hooks set as above.

> 2) Let's say the senior developer doesn't like the last revision. Then he 
> can disapprove it and revert it to the previous revision?

Yes, but be careful about disapprove - it is (alas) not the inverse of
approve as the name might seem to imply.

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

--
Dan.

pgp4PNmJiexXV.pgp
Description: PGP signature