In Monotone, all trust is handled on the basis of certificates (called certs).
Certs and Revisions
Every revision is identified by a cryptographic SHA1 hash that represents both the entire content of that revision, and its fixed ancestry. Certs are issued and signed by developer keys, and each cert makes some kind of assertion about a revision: membership of a branch, fitness for a particular purpose, passing a particular QA test, etc. See UsingCerts for examples of standard assertions that are commonly made about revisions.
Each user can configure their own preferences about which certs to trust for what purposes.
My purposes might vary between different branches and workspaces:
I might have a workspace tracking the main open development branch. In that workspace, or that branch, I will accept revisions signed by any known project developer.
I might have another workspace tracking a release branch. There, I require additional certs from nominated release engineering staff, and a successful autobuild test (and other possible criteria) on a new revision before it's considered fit for updating to.
Someone else can have different preferences and different trust settings. We could, if we felt like it, even have different sets of developers we considered trusted, such that I might ignore revisions from someone I considered unreliable, until they were validated by someone more trustworthy in my eyes.
Syncing and Merging and Delayed Trust
In monotone, the processes of syncing information between repositories, and merging work between revisions, and trusting revisions are all separate.
In other similar distributed VCS systems, one or more of the syncing, merging and trusting steps are combined. For example, trust is often combined with syncing, so that the trust happens at communication time. Syncing might also be combined with merging, so that in order to exchange work with someone else, we have to merge our work as we go. In such systems, every replication between repositories is a merge that must include a trust evaluation on the part of the person doing the merge. If I merge with someone else's repository, I must implicitly and completely trust the entire merge and trust history of that repository (and all of that person's previous merge trust decisions), and I don't get anything to strongly identify and evaluate that history and its original provenance for myself, post fact.
In monotone, they are separate:
Syncing between databases is simply a matter of passing around revisions and certs, and implies no specific trust in their content.
Once I've learned of new revisions, I can disconnect from the network, and decide what to do with them. I can
mergethem with my own work,
checkthem out, do
diffs, or simply ignore them entirely.
Trust in the content is evaluated in these later steps, such as when I want to
updatemy workspace to a new revision I've just learned about over a
sync. (There are permissions on who is allowed to
sync, and these relate to keeping revisions private and avoiding anonymous cranks filling your DB with garbage, but that's mostly separate to trust evaluation for the content).
So, when I
sync with someone, I might learn of a whole pile of
revisions and assertions about those revisions, and take them into my
database. That in no way means those revisions are trusted for
anything. Merging of divergent revisions, whether explicitly named
just multiple little parallel edits, is done as a local command just
like any other change/commit to the repository, and creates new
revisions with the merged content (that you can then publish back to
I can change my trust preferences at any time (or have
different preferences for different purposes), and the trust in
revisions is reevaluated as needed based on the assertions in the permanent certs
that were recorded with the original revisions.
For example, I could
set up a workspace to evaluate experimental revisions -- such as code
submissions from 'strangers' I wouldn't normally trust on mainline
code. The trust settings for that workspace would allow me to
update it to those revisions, look at their submissions
approve (adding my own certs) some
of them as being appropriate for other purposes. On the basis of these
additional certs that represent code review, these revs might then be
considered trusted elsewhere (in my other workspaces, or by other
Furthermore, I can communicate with someone else at any time, quickly and safely and easily, without having to evaluate content trusts or do any merging work. That work can be done later, and seen later as a separate step with its own historical record. This can be vitally important for backup purposes and distributed working, because there are no impediments to publishing revisions quickly. I don't have to review someone's code in order to take a copy of it using the tool. I can even then pass it on to someone else, who can make the distinction between my work and what he receives from me over the network, and make trust decisions accordingly.
The downside of this with the present monotone implementation, is that currently the only way to do this is per-user, so each user must configure their own trust settings (or copy them from a handy central place or revision signed by someone they consider a worthy trust seed).
Mechanisms to automate this, and allow delegation to a 'project authority' for common VersionedPolicy statements that affect trust evaluation are the next major development focus.