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. 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'). You change then the hook get_revision_cert_trust() (either in $HOME/.monotone/monotonerc or _MTN/monotonerc). 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). Now I'm curious if my explanation is correct. Dan? ;) Boris > [...] _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
