This page is one of many describing EvaluationFeatures that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems.

Description

Provide Access Control features to provide limits over the actions developers can take

Supported

Monotone has extensive and extremely powerful features for deciding which developer actions should be accepted. However, they're quite unusual and quite different from what other systems offer. So much so that people coming from existing VCS tools (especially centralised ones) might not even recognise them as Access Control features at first.

In monotone, it is far more important what comes out of the db than what goes in. These features concentrate much less on restricting what a developer can do or say or publish into the repository, and much more on giving the end user the power to be selective about how and when they use that information later. Network exchange is a simple communication of facts (file contents and revisions) and assertions about their value (in certs) - but those assertions may not necessarily be believed. The TrustFoundations page describes how these concepts work in more detail. There are simple netsync permission hooks that mediate basic access control to servers, but everything else is better done via trust evaluations at the time of usage.

In part this is a recognition of the unavoidable consequences of the offline, distributed nature of the system - any programmatic attempt to restrict software behaviour is subject to tampering by someone in full control of their own system and database contents. But it turns out to be a far better way to deal with a number of other requirements as well.

Access controls are applied by users over what revisions and developers' code can come out of the database and have access to their workspace. Users can have different workspaces, for different purposes, with different trust settings appropriate to each purpose - taking revisions and information from the same database. New assertions can be made about old revisions at any time, and these may change how and where those revisions are considered trusted.

For example, a common use for these kinds of features in other VCS tools is to restrict commits in specialised branches to a limited number of approved committers. In a centralised system, these controls would be enforced by a MasterRepository. Release Branches are a common example, where a release engineering team must review and approve all changes. In monotone, the revision can be committed first, published, then reviewed, and finally approved onto the release branch by someone developers trust to make statements about code quality for that branch. This is just one example, and the capabilities are very powerful indeed.

However, the flip-side of this unusual approach is that few projects are accustomed to working this way, and many users don't want to have to configure these kinds of rules for themselves. Monotone allows a very distributed and loosely structured development community to share information much more readily than they might with other tools, but many projects are more structured and generally involve certain authority figures who most users are happy to delegate these trust decisions to. The next major feature development effort in monotone, now that the core VCS functionality is robust and stable and mostly complete, is a set of VersionedPolicy mechanisms. This will allow users to delegate the configuration of these trust decisions to a suitable project authority or authorities for the sake of simplicity and convenience.

Further Reference

Manual and Tutorial Sections:

Features and Requirements in other evaluations: