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

[Timothy Brownawell]

On Thu, 2006-11-30 at 23:41 +0000, Boris wrote:
> Hugo Cornelis wrote:
> > An additional question :
> >
> > I have a project consisting of three parts :
> >
> > 1. A = Markov channels
> > 2. B = cable equations
> > 3. C = other things.
> >
> > I am the expert for the cable equations, J is the expert for markov
> > channels.  We both work on the other things as well.
> >
> > Is it possible to use certs to sign changesets as having impact on
> > parts A, B and/or C, e.g. based on the filenames in the changeset ?
> > If so, what is the best approach to setup such a mtn db ?
> >
> > Then, I can use the certs to automate merges and propagates for
> > trusted changesets: e.g. the goal would be that if I change something
> > that has impact on part B, J will need to approve these changes when
> > he merges in my new code, but he does not need to approve changes that
> > impact A or C.  Is this correct ?  The fact that the repository is
> 
> Hugo, I try to answer your questions although I was asking lots of questions 
> myself. Some of the guys who know monotone much better than I do should jump 
> in and correct me if I say something wrong. It will help me to understand 
> monotone better, too. :)
> 
> Here's my answer: What you want to do can be done. 

I think so, yes. But not in a really straightforward way.

> You can attach any kind 
> of value/name pair to a revision and create a new cert for your own purpose 
> (see 'cert id certname certval').

Yes, I'd suggest having a bot that inspects all new revisions (there's a
ciabot script in contrib/ that could be used for inspiration) and adds
whatever cert you need. (We have a note_commit hook, but it's probably
called with the database still locked. So no having it call another
monotone to add certs.)

The hard part is getting monotone to look at this cert at the right
time.

> The hook get_revision_cert_trust() is called for every 
> value/name pair with a table (list) of signers. What you want to do here is 
> to check if your new value/name pair which indicates the "impact on A, B 
> and/or C" is present *and* if the revision has been approved by J (then the 
> value/name pair branch="<branchname>" should exist and should be signed by 
> J).

...but, it only sees *one* name/value pair at a time. So I don't think
it's possible to say "the presence of a cert saying X was edited means
to not trust a branch cert by Y".

What you could maybe do is use testresult certs, since monotone *does*
specifically consider those for update. But, it doesn't look at them for
branch membership, so that's not quite what you want.

...What *else* you might try, that might actually give what you want, is
to have the "foo was changed" cert actually be an extra branch cert, for
the same branch you're putting it in, but signed by a special key that's
only used for this. Then when the trust hook gets called on the branch
certs, look for that key in the signers and require that it always be
accomanied by the key of whoever owns "foo".


Really the trust hooks need to be reworked somewhat. Probably, this will
be part of the "policy branch" stuff we're (vaguely) planning. (Wild
guess of 6 months out, maybe? IIRC rosters were somewhere in that
ballpark.)

-- 
Timothy

Free (experimental) public monotone hosting: http://mtn-host.prjek.net