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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel