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

[Daniel Carosone]

On Thu, Nov 30, 2006 at 04:11:24PM -0600, Hugo Cornelis wrote:
> 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 ?

There are two ways to look at this, and they may work well together.

You probably want to treat these three things as separate branches for
development.  Then you want to use the branch assembly pattern to make
an integration branch for the overall project that collects the three
parts together:
 mtn merge_into_dir org.project.markov org.project.integration markov
 mtn merge_into_dir org.project.cable  org.project.integration cable
 mtn merge_into_dir org.project.common org.project.integration common

Or you just use the same mainline branch for common and integration:
 mtn merge_into_dir org.project.markov org.project markov
 mtn merge_into_dir org.project.cable  org.project cable

Then you wind up with subdirectories called markov and cable in the
mainline/integration branch that are 'copies' of specific revisions of
the relevant subbranches.  Development for those subbranches happens
separately, and can be propagated to the (subdirectory in the)
mainline as needed.

> 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
> distributed does not have impact on such a work method, correct ?

If you make changes to the code in the markov branch, J might want to
review them before accepting them, yes.  If J wants to propagate that
branch to integration, you can accept that directly and consider that
his approval of the changes for mainline use.

This doesn't detect you making changes to the copy of the markov code
in the integration branch, however.  So regardless of whether you do
the above thing to organise code for normal work, or whether you just
do everything in the one branch anyway, you can flag this a number of
ways:

First, the trust evaluation hook gets a copy of the revision id, which
you can use to look up the change set to parse.  This could be slow
and would be done over and over (each time the rev is evaluated for
trust).

Better would be to use a testresult cert, and write a test that parses
the changeset and issues certs for "complies with markov code path
restrictions policy". See the TrustBot page for more background about
encapsulating complex decisions in an additional cert.  Then your
trust policy would require an additional cert from J to approve any
revs that initially failed this test (another testresult, a custom
cert, or just a branch cert signed by J rather than someone else).

Or you abstract further: have the TrustBot issue branch (or
testresult) certs for revs that:
 - meet the pathname policy, or
 - don't otherwise meet the policy but have a branch cert from J
 - also pass a collection of other tests and criteria
 
Then you only look for that cert, and don't worry about J's cert or
the other individual test certs so much.  Developers would commit
revs, the TrustBot would either bless them or not.  If not, J can
review them, and add his own cert.  When that new cert arrives at the
TrustBot (see the note_netsync_* hooks), it can reevaluate the certs
on that rev and issue its cert at that time.

That's the theory. Concrete implementation examples welcome! :)

--
Dan.

pgpMppnRQEOPQ.pgp
Description: PGP signature