[Monotone-devel] Re: [RFC] versioned policy -- introduction

[Wim Oudshoorn]

Timothy  Brownawell <address@hidden> writes:

> On Sat, 2006-09-09 at 20:51 +0200, Wim Oudshoorn wrote:
>> SCENARIO I:  Non project leader commits to branch FOO.Stable
>> ------------------------------------------------------------
>> 
>> Expected behaviour:
>>          This commit should not by default be visible in the UI,
>>          so nobody will by accident check this revision out and 
>>          expect it to be a stable version.
>> 
>>          The commiter either gets a warning and/or can just
>>          continue working on the FOO.Stable branch, but nobody
>>          will see it.
>
> The committer gets an error, and must give a --force option to make
> monotone accept the commit. Nobody will see their commit.
>
>> SCENARIO III: A project leader leaves
>> -------------------------------------
>> 
>> Expected behaviour:
>>          The new or remaining project leader can revoke
>>          the 'commit' rights to the FOO.Stable branch.  However
>>          all certificates handed out by the ex-project leader up to
>>          the date he left are still considered valid.
>> 
>> 
>> Problems:
>>         
>>         Suppose we have in FOO.Stable the following
>>         
>>         history:  Rev A (VERSION=0.1, signed by: ex-leader, 
>>                    |     at that time project leader)
>>                    |
>>                   Rev B 
>> 
>>         Now the the project leader leaves and we want 
>>         to keep valid the signed Rev A, but not any later revs.
>> 
>>         Because we can't trust the date certificates it is no use
>>         adding a date to the revoke.
>> 
>>         Suppose now the ex-leader does the following:
>> 
>>                 Rev A (VERSION=0.1)
>>                    |  \
>>                 Rev B  \ 
>>                        Rev C (VERSION=0.2, signed by now ex-project leader)
>> 
>>         and synchronizes with our database.
>> 
>>         If a user does monotone co -r c:VERSION=0.2, what happens?
>
> The control branch has multiple conflicting heads, which is an error
> condition. Either the heads will have to be merged, or the users will
> have to explicitly choose which one to use.

What do you mean exactly with the 'control branch' has multiple heads?
Anyway, I don't think this is desired behaviour.
Suppose I am the new current accepted project leader. 
Just after rev B has entered my database, but before
rev C is present I decide to demote the ex-proejct leader
to a normal developer. 
What I don't want is to after every sync check if by some
accident a rev C in stable appears with confusing certificates.
from that point onwards in time the ex-project leader should just
be a developer so, scenario I should apply.
Especially so, becuase if I as a new project leader miss this situation
it will end up in the database of all my users who will
be very confused about the situation. They suddenly see a VERSION=0.2
apparantly signed correctly.


To put it differently:

    my mind works rather linear. That means that I inspect
    my database and change trust settings in way I am happy.
    Afterwards I expect that these trust settings apply
    for everything that ENTERS my database.  


Maybe this fundamentally impossible, but I don't know.
Why not build a lot of the trust at the gate?
Decide what comes in my database and what does not?

Wim Oudshoorn.