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

[Boris]

Timothy Brownawell wrote:
> On Fri, 2006-12-01 at 01:01 +0000, Boris wrote:
>> Timothy Brownawell wrote:
>>> [...]
>>>> 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".
>>
>> Then I interpreted the documentation right at least. :-) If you have
>> a revision with the four certs for branch, author, changelog and
>> date the hook get_revision_cert_trust() is called four times, right?
>> Only if get_revision_cert_trust() returns true four times the
>> revision is accepted (for example by 'mtn update')? This means we
>> have a kind of AND-condition between the four certs. What Hugo was
>> asking for was something like an AND-condition for the "foo was
>> changed" cert and "approved by J" cert but only if the "foo was
>> changed" cert exists.
>
> No, each name/value pair is considered independently. So no
> AND-condition between certs with different names (or different
> values).

But what happens if the cert for date for example returns false while the 
other three return true? Isn't this revision then rejected for the branch 
(actually any branch)? Or is the only check which is important the one for 
the branch cert?

>> I don't know Lua enough yet. But why aren't all of the certs simply
>> passed in one call to get_revision_cert_trust()? Then it should be
>> easily possible to AND/OR/NOR whatever you want to do?
>
> Because it's deciding whether we want to trust that particular
> name/value assertion, rather than whether we want to trust the
> revision itself. Which means we can, say, trust a rev for use in one
> branch but not another.

I see. In order to support this in Lua the branchname would need to be 
passed to the hook, too? (not a request - just trying to understand the 
details :)

Boris