Unity Version Control

Plastic SCM
	File:PlasticSCMLogo.gif
Developer(s)	Codice Software
Stable release	3.0.1 / July 28, 2010; 14 years ago
Operating system	Microsoft Windows, Linux, Solaris, Mac OS X
Platform	.NET
Size	33MB
Type	Revision control systems
License	proprietary
Website	www.codicesoftware.com

Plastic SCM is a commercial, proprietary revision control tool developed by Codice Software, Inc.

Plastic can work in centralized mode (with a central server) and as a distributed revision control system.

Architecture

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 (software) and mercurial do).

The Plastic server stores data and metadata on a relational database. The database can be one of the following:

SQL Server
Firebird
Oracle
SQLite
MySql

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.

Server

Database

The default Plastic database on a regular installation is a Firebird embedded database on Windows systems and a SQLite embedded database on Linux and MacOS X (since Plastic 3.0).

The database can be configured by tweaking the db.conf file located on the server directory and can be set up to use any of the other alternatives.

The database can be queried to extract extended information. All data and metadata are stored in the database.

Administrators can set up their preferred database system and set it up to run backups, disaster recovery and high-availability.

Every repository is stored on a separated database, except in case of Oracle, where every repository is a different user and tablespace.

Clients

There are different kinds of clients:

Command line tool: cm
GUI tool: plastic
Integrations with third party IDEs, most notably Visual Studio, Eclipse, IntelliJ and any SCC compatible environment^[1].

The command line tool can be use for automation. It can run in "shell mode" (cm shell) where the command stays open and receives orders through the standard input, saving restarting the process for every command for high performance integrations.

Features

Complete file and metadata history
Revision history for branched, renamed, moved, copied, and deleted files
Rename support, also across branches
Graphical representation of the history of files and directories through the 3D version tree
Graphical representation of the evolution of the repository through the branch explorer^[2]
Three-way text file merging; merge tracking and re-merge prevention; common ancestor detection
Graphical diffing, merging, and offline/online reconciliation tools
Graphical file content history and branch history viewers
Centralized, access-controlled repository with support for distributed revision control (see below)
Atomic commits -- the server assures that changesets are committed in their entirety
Shelving -- users can save and restore work in progress for task switching
Support for ASCII, Unicode, binary, symbolic link (on Unix), Mac-specific, and UTF-16 files
Support for Mac OS X, Windows and Linux platforms
Server-side and client-side event triggers
Programmable command line client

Concurrency model

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 not the default nor 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 us Subversion or Git (software) are used to.

Branching

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)

Merging

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.

Distributed revision control

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.

Access control and security

Plastic differentiates from access control and security. User and group information can be retrieved from one of the following sources:

LDAP
Active Directory
Built-in user/password
Local users on the client and server machine (if the network is secured, Plastic is secured, otherwise there's no secured auth in this mode)

Every object in the system has an associated access control list (ACL)^[3] and there is a set of 32 different permissions to tune security.

Availability, release cycle and supported platforms

Free downloads of Plastic server, client, and plugin software are available from Codice Software's website.

Major releases of server and client software are typically published twice a year as pre-built executables for Microsoft Windows, Mac OS X, Linux^[4], and other operating systems. Minor releases are available on a weekly basis.

Licensing and terms of use

Free licenses are available for open source software development, school or classroom projects, and trial/evaluation periods.

Commercial licenses are available.

References

External links

[1] Third party tools compatibility matrix

[2] Branch Explorer explained

[3] Plastic SCM ACL-based security

[4] Miguel de Icaza on Plastic SCM UI on Linux and Mac OS X

[1]

[2]

[3]

[4]