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.

Trusted 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 merge them with my own work, check them out, do diffs, or simply ignore them entirely.

• Trust in the content is evaluated in these later steps, such as when I want to update my 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 branches or 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 other repositories).

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 and 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 developers).

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.

Individual Trusts

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.