According to its creators, Plastic SCM tries to fill the gap between open-source distributed source control platforms as Git or Mercurial and enterprise platforms such as Perforce or ClearCase. The product launched its first versions in early 2007, and starting with version 4.0 the internal architecture has been changed to a Directed Acyclic Graph (DAG). In 2012 support for git synchronization has been announced.[1]

The command line tool can be used for automation. It can be run in "shell mode" (cm shell) where the command stays open and receives commands through the standard input, avoiding to restart the process for every command what is useful for high performance integrations.

Plastic is a client/server system although in current terms of version control it can also be defined as a distributed revision control system, due to its ability to have very lightweight servers on the developer computer and push and pull branches between servers (similar to what Git and Mercurial do).

Developers work on files in their client workspaces, and check in changed files together in changesets.

Communication from client to server is done through a customized .NET Remoting channel.

Plastic is based on a branch & merge concurrency model. Optionally it is possible to do exclusive checkouts in order to prevent concurrency, but it is neither the default nor the recommended way of working.

A checkout in Plastic doesn't mean a lock. It just means a new revision of the item is created in order to be edited. Several checkouts of the same item can be performed in parallel on different workspaces, even on the same branch.

In the default checkout and change model, users are expected to let the system know in advance which files they intend to change, even if they do not mean to lock them (similar to Perforce).

Since version 2.8 it is also possible to perform a change and commit cycle in which a previous checkout is not needed, as developers from systems such as Subversion or Git are used to.

Every item (file or directory) is identified by a unique id instead of a path.

Files do not have names directly associated, but as it happens with a file system, directories handle all naming. It makes renaming a very cheap operation.

Branches are defined as revision containers. Creating a branch doesn't perform any copy of revisions, it simply creates a new empty object.

Plastic branches are hierarchical: there's always a main branch (by default named /main) on every repository and normally all branches are created as child branches. A child branch means it inherits everything from its parent except the contents it already has. So, after creation, a branch is empty but it inherits its contents from the parent branch.

That's why when a new branch is created on Plastic it doesn't have any contents but if a workspace is switched (updated) to the branch the workspace won't be empty.

Branches with hierarchy are also known as smart branches and their inheritance can be set up as follows:

Inherit from a specific label

Inherit from a specific changeset

Dynamic inheritance from the parent branch, which means a change on the parent branch will be directly inherited to the child branches set up with dynamic inheritance

Branching is a cheap operation and the recommended workflow with Plastic encourages the creation of many branches (branch per task)

As of version 3.0 merge tracking information is kept on a per item basis. Every file and directory keeps track of the merge links between its revisions. Merge tracking information is used to calculate the nearest common ancestor of the two candidates on a merge, and parent links and merge links are weighted differently.

Merging is meant to be a focus feature of Plastic, and the system is built around this capability.

Plastic is able to push and pull branches from remote repositories, and merge conflicts if modifications happened on the same branch on two locations concurrently on the same files or directories. In case of conflict during push or pull operations, a fetch branch is created containing the fetched revisions. The branch can be merged later.

Plastic also provides a proxy server that caches frequently accessed revision data and can be used to reduce traffic on centralized setups.