Timothy Brownawell <[EMAIL PROTECTED]> 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. _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel