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

[Wim Oudshoorn]

Nathaniel Smith <address@hidden> writes:

>
> Questions, comments?
>
I have tried a few times to understand the versioned policy discussions, 
but everytime I ended up even more confused. 

So is it possible to have a few detailed use cases.  Take for example
the problem of revoking commit access.  It is easy to state it just like
that:  I want to revoke commit access for user joe.
However this leaves out a lot of details on the actual expected behaviour of
monotone.  All I see is a discussion about trust seeds and trees and no
detailed use case yet.  And this might be just me, but it makes it much
harder for me to reason about the probosed solutions.

Ok, enough complaining.

Now let me try to sketch a few scenarios.


GENERAL SETUP
-------------

1 - There is a public project working on FOO
2 - Project FOO has a few, 2 or 3 project leaders who drive the project
3 - Project FOO has about 10 other developers commiting code once in a while
4 - Project FOO is structured by having two main branches:

    FOO.Stable          -  containing code that is considered stable
                        -  certificates of the form VERSION=1.0 etc are used
                        -  to denote releases
                        -  only the project leaders should commit to this branch
                        -  only the project leaders should be able to add 
certificates
                        -  on this branch
    FOO.Unstable        -  All the 10 other developers should be able to commit 
to this branch


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.


SCENARIO II: Project leader by accident signed a revision with VERSION=1.1
--------------------------------------------------------------------------

Expected behaviour:
         The project leader can do some magic with monotone so that
         people will, by default, not see this certificate.
         (Assume that the database is already sync'ed with lots of other
         people)

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?

                    
SCENARIO IV: My private work
----------------------------

Setup:

        I am using project FOO as part of my great application BAR.
        I want to develop by using FOO as component, so what I do:

        1 - create database containing FOO.Stable by synch with the project
        2 - create branch BAR by ading lots of files
        3 - happily develop and sometimes in branch foo and sometimes in bar.
        4 - sync with the project.




            FOO.Stable       FOO.Unstable     FOO.Mine       BAR
                                                 
                A                 
                 \_____________________________ B
                                                | \__________ C
               .                 E              D             |
               .                  \ ___________/ \___________ G
               .                   F            |
                                                |
               H                                |
                \______________________________ I


         my work in foo will be neatly synchronized with the project
         by merging in fixes in FOO.Stable with FOO.Mine

         I will make private fixes as in revision D and 
         merge them back in FOO.Unstable for later inclussion
         in the FOO project.
         
         I will merge FOO.Mine changes into the my own project BAR, like rev G

         
Expected behaviour:
         If I sync after mergin my fixes in FOO.Unstable
         I don't want my BAR branch to be send over the wire.
         I do want to have my own policy on the BAR branch, which
         should not be send over the wire too.
         I I am happy to work with the FOO policy.
                            

OTHER REMARKS
-------------

The scenarios above are rather benign.   I can think of 
nastier ones.  But lets assume that we have no really evil
persion in our midst.  If the evil person appear I think
you should ban all writes from that person.  But
that is a scenario for another day.

Wim Oudshoorn.