[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: [RFC] versioned policy -- introduction
From: |
Wim Oudshoorn |
Subject: |
[Monotone-devel] Re: [RFC] versioned policy -- introduction |
Date: |
Sun, 10 Sep 2006 08:44:50 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin) |
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.
Re: [Monotone-devel] [RFC] versioned policy -- introduction, Timothy Brownawell, 2006/09/08
[Monotone-devel] Re: [RFC] versioned policy -- introduction, Wim Oudshoorn, 2006/09/09