Re: [Monotone-devel] Re: user-friendly hash formats, redux

[Oren Ben-Kiki]

On Saturday 11 December 2004 01:15, Jonathan Matthew wrote:
> > ... if you want someone else to be able to commit to the branch,
> > give him a copy of the key.
>
> This would make it awfully hard to revoke someone's access to the
> branch,

Being able to revoke permission, and at the same time not being able to 
revoke certs - Hmmm. Tricky. Can you do it?

> and unless you require the branch key to be used in 
> combination with a personal key, you have no record of who actually
> committed each revision in the branch.  Not a good combination.

Since developers always create revisions using their personal keys, you 
know who created what. The only information you lack is who _merged_ 
the revision into the main line. As you point out, this is trivially 
solved by adding a cert signed by the merger's personal key.

> The phrase 'give him a copy of the key' just makes me extremely wary.
> It makes it very hard to define who is trusted to commit to the
> branch, and that's something I (or my corporate overlords, at least)
> would definitely like to be able to do.

You could use more complex methods - e.g., once you created a 
fork/branch, create a cert (signed by the owner's key) that grants 
certain privileges to other keys for a limited period of time ("the 
author 'bob' can commit revisions to the main line during the next two 
weeks").

Of course, the details tend to be different from one person/company to 
another. It blurs into issues of workflow definitions ('bob can only 
merge a revision to the main line if his team leader alice signed a 
code review and anyone from charlie's team signed some set of 
restresults').

An effective way to side-step this issue altogether is to allow anyone 
to freely add information to the database, faithfully record all 
relevant meta-information (who did what when), and define a set of 
(Lua?) hooks to specify policy.

This is similar, but not identical, to what Phil de Joux proposed. In 
both cases there's basic "core" functionality that uses hashes to 
identify revisions, allows anyone to create revisions, and allows 
arbitrary signed certs to be attached to revisions. This is almost 
exactly what Monotone is today (minus special certs such as testresult, 
branch etc.).

The more complex issues of "workflow", which touch on branching vs. 
forking (currently implemented by "branch" certs), "friendly" ids 
(currently implemented by "tag" certs), what is a "good" revision 
(currently implemented by "testresult" certs), and permissions 
(currenly none) would be defered to a distinct, separate layer.

So far, I think Phil and I are in agreement; strong architectural 
separation between the core and workflow layers is a good idea. Phil 
was vague about one point though, where we might have different views. 
He said the workflow layer should be in some user interface "service". 
I don't like the thought of this being contained in a specific user 
interface _tool_ - if that's what he had in mind. I would like to see 
the workflow layer defined as an plug-in framework (set of Lua hooks or 
whatever), so that every user interface tool accessing a db would share 
the same workflow logic.

The current Monotone architecture has some hints its going in this 
direction; the testresult certs are an obvious example. However, they 
aren't very developed at the moment, and they only cover some of what I 
would expect a workflow layer would do (specifically, the whole notion 
of branch/fork/friendly-id, and, of course, permissions).

The core vs. workflow separation calls for a different focus when 
developing Monotone. It should be more on primitives and less on 
high-level commands. For example, you would focus on a single core 
"merge revision A with revision B using revision C as a base" command 
instead of three separate workflow update/merge/patch commands. Most 
(all?) of the special certs support would be outside the core. I have a 
strong suspicion that the core should also allow revoking certs (to 
support things like revoking permissions, revision renumbering, etc.).

The higher level commands should be clearly separated from the core and 
implemented in such a way that they are controlled by (Lua?) hooks and 
implemented purely in terms of core commands. Defining the "right" set 
of high level commands would be a tricky - you need to come up with a 
set of operations that are both specific enoughfor a user to use 
meaningfully, and at the same time are universal enoughfor any 
reasonable workflow to be implemented. I _think_ this can be done 
(e.g., merge vs. update vs. patch), but it requires *very* careful 
thought. You'll probably have to throw in a concept of "revision state" 
and commands that manipulate that (using testresult as a basis).

The important point to keep in mind is that special certs are only 
special because the particular implementation of the workflow commands 
treat them as such. So, if I need a new type of cert to implement a new 
type of permission system (say), I can do that. Since the Lua code for 
the workflow commands is part of the project, any UI that accesses the 
db can make use of them.

In contrast, Phil's approach (just let the UI do it) is much simpler. 
There's no universal set of commands; rather, there would be an 
"Aegis-like system for Monotone" vs. a "Basic system for Monotone" vs. 
the "IBM system for Monotone", implemented in code and using Monotone 
as an intelligent version-control back-end database system ("The SQL of 
version control"). This means the set of commands is just right for 
your workflow. However, if your db uses one such UI, you can't use 
another.

Currently Monotone hasn't made a strong distinction between "core" and 
"workflow" operations, but it does have some obvious generic "workflow" 
commands such as "update". Evolving Monotone in the direction of a 
two-layered architecture with "universal" commands should be pretty 
easy...

Have fun,

 Oren Ben-Kiki