[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Re: user-friendly hash formats, redux
From: |
Oren Ben-Kiki |
Subject: |
Re: [Monotone-devel] Re: user-friendly hash formats, redux |
Date: |
Sat, 11 Dec 2004 12:26:01 +0200 |
User-agent: |
KMail/1.7.1 |
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
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, (continued)
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- [Monotone-devel] Re: user-friendly hash formats, redux, graydon hoare, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Jonathan Matthew, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux,
Oren Ben-Kiki <=
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Patrick Mauritz, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/09
- [Monotone-devel] Re: user-friendly hash formats, redux, Bruce Stephens, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Brian P. Campbell, 2004/12/09
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathaniel Smith, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Oren Ben-Kiki, 2004/12/10
- Re: [Monotone-devel] Re: user-friendly hash formats, redux, Nathan Myers, 2004/12/10