Version control is the operating system of software development. It can solve problems efficiently and silently, or it can create more. Plastic SCM is a distributed version control, but can work centralized too. It is excellent with branching and merging, can deal with huge projects and big binary assets natively, and it comes with GUIs and tools to make everything simpler. Plastic solves problems.

Branching & Merging
Good branching and merging is key for “task driven development”, feature branches and good release management.

Using Plastic you’ll branch fast even with huge code bases.

You’ll handle merge cases that no other tool can deal with.

Fully distributed
Using Plastic a developer can have a clone of the repository on his local machine and checkin, branch and merge without connection to the main server. This is what fully distributed is about.

The benefit is clear in terms of speed, enabling developers to work from home without suffering slow VPNs or being hit by a network issue. Developers can pull and push changes to any other Plastic server (depending on the permissions) anytime. In extreme distributed environments, developers wouldn’t even use a central server. However, in practice, a central place will be used as rendezvous point.



Graphical User Interface and Visualizations
Plastic is much more than a scalable core and a great merge engine. Everything we do has the end user in mind, and making things simple and visual is key for us.

Plastic allows you to perform every version control operations from the GUI, which is pretty easy to learn. User experience is our most important goal.

It is the core feature of the GUI. It is an interactive graphic that renders the evolution of the repository. From the Branch Explorer you can branch, merge, diff, push and pull and switch to different branches. If there is a single feature that makes Plastic worth, this is the Branch Explorer.

Plastic ships with an integrated code review system. You can create reviews from changesets and branches, add comments to lines and assign the review to a developer to check it. Reviews are replicated between repos with their branches.

You can display the history of a file visually using a 2D version tree. Then you can follow how it was branched and merged, and run diffs from the diagram.

This view shows who wrote every line of and file. Each line is annotated with the date, the changeset and the branch. Additionally the annotate displays the line age and it can summarize the file age and main contributors.

Plastic includes a built-in diff tool, Xdiff, which can be invoked as a separate tool but it is also used inside the GUI to show side by side differences. It has the ability to track moved text (even when it has been modified). You can find this in Plastic, inside the pending changes view, diffing changesets or branches or running code reviews.

Plastic comes with its own 3-way merge tool called Xmerge. Besides being a regular merge tool, it has the ability to track and merge moved code fragments. Plastic also lets you plug any other 3-way merge tool like Araxis, BeyondCompare, our own SemanticMerge and many others.

Each time you need to diff branches, changesets or labels you’ll use the Diff Window. It is a very complete interface that will show changed, added, deleted, moved and also files that have been merged in the changesets, labels or branches you’re diffing.

Plastic includes a image diff tool, able to compare two revisions of the same graphical file. The file can be in a variety of file formats (specially if you have ImageMagick installed). This tool can show images side by side, do an “onion skin” preview, calculate differences, do a “swipe” and also diff the image properties in text format.

When you browse the files in your workspace you can preview the image files and read the extended properties stored on it. Plastic can be configured to use ImageMagick to generate the previews of hundreds of different formats. You can even write your own custom previewer to support custom file formats (quite common in game development). It will also be used to diff image files.

We created support for 2 different workloads in Jet:

Small server workload support: perfect to handle local repository replicas on laptops and workstations and even small team servers. It focuses on performance and not scalability
High-scalability workload support: a more complex alternative focused on scalability workloads.
We still support SQL databases (MySQL, SQL Server, SQLite, Firebird and a few others) but Jet is enabled as the default backend replacing SQLite during evaluations. For Enterprise, the high-scalability engine is enabled.

We believe that version control holds a unique position to give developers extra tools for the job. It stores all the evolution of the project and hence information that, correctly mined, can help in daily operations. That’s why we created SemanticMerge first, and then we applied the technology to the version control itself...

You can now diff a branch or a changeset and easily diff methods even when they were moved between files and later modified. Plastic analyzes the diffs to find refactors and eases diffing and reviewing the code.

This feature is also known as “multi-file” semantic diff and is included in Plastic for C#, Java, Vb.net and C.

Each time you diff a branch, a changeset, or your local pending changes, you can activate “semantic diff”. Plastic will parse the files and calculate the differences semantically, method by method, finding the right diffs even when a method was moved, renamed or was heavily modified.

90% of the time you go through the history of a file you are actually looking for the history of a given method or function.
Semantic History lets you select a method and find how it was modified through the history of the file. It parses the code and it is able to find the method even when it has been moved, renamed or heavily modified through history.

It all started with Xdiff/Xmerge, able to track moved text (language independent) and then continued with SemanticMerge and Analyze Refactors. Our next goals are:

Semantic Repo History: to track methods moved across files.
Multifile SemanticMerge: the *real* Semantic that will be able to merge methods that were refactored across files too.
Semantic blame/annotate: to give the programmer extended info of each line of code and method while he types on Visual Studio, warning him about code that has a long and complex history behind, bugs and more.

Performance & scalability
Checkin, update and merge as fast as possible. Handle hundreds of concurrent developers using the same server. Manage huge files. These are the things you can do with Plastic.
Scalability under heavy load
Check how Plastic performs when 300 bots checkin at 2000 checkins per minute. Scaling up on centralized setups is key for many teams, and core to Plastic.

Improved blob storage New in 5.4
Big blobs (configurable size) can be stored in the filesystem instead of the database for storage optimization and performance.

Single port operation & binary protocol
All data transfer between the Plastic client and server uses an optimized binary protocol that compresses all metadata to speed up communications. All connections between clients and servers happen through a single TCP port (several can be configured if needed, but only one is needed by default) which makes the server very easy to configure and secure.

Proxy server
Although Plastic is a full featured DVCS capable of replica, we also provide a proxy server (or cache server) to reduce data traffic to the central server. We don’t recommend this setup for multi-site but for high demand, heavy load scenarios where reducing data traffic on certain network segments can greatly improve overall network performance. Check this blogpost for more details.

Fast-update New in 5.4
Standard Plastic update (download files to the workspace) walks the entire directory tree looking for changes. It is very efficient, but teams with really large codebases (>500k files) can end up experiencing slower IO and slower updates. That’s why fast-update just applies differences on disk, avoiding the full scan. Going from cset 3000 to 3014? It just calculates the differences and applies them on disk, reducing disk IO and improving speed.

Archiving – External storage
You can extract revisions of large files from the database to be stored in secondary storage. Once archived the revisions can be accessed in two ways:

Transparently for the users when the server is setup to find archived revisions on external storage.
Prompting the user to insert the right media on his workstation (useful if your team uses an asset library in different media)
WAN optimized data transfer New in 5.4
Teams with servers on different continents replicate branches through high bandwidth but high latency networks. The “WAN network channel” typically improves data transfer speed by 3 with 200ms latencies compared to regular TCP. This is very useful for companies replicating big files between different teams across the globe. Find more here.

Multi-thread checkin and update New in 5.4
Checkin and update can be configured to use multiple threads. This way data compression and decompression will run in parallel with network and disk IO operations, greatly improving overall operation performance as you can find here.

Configurable database backends
Plastic stores all data and metadata in standard database backends. The default installer uses SQLite on Windows, Linux and Mac. You can easily configure it to use SQL Server (including Express), MySQL (and MariaDB), PostgreSQL or Firebird (both embedded and server). This flexibility allows you to run a tiny and extremely Plastic server using SQLite on your laptop, or take advantage of a corporate server with SQL Server or MySQL.
SysDBAs have the flexibility to setup clusters and apply optimizations since Plastic uses standard SQL structures. Backup is done with standard tools too. Blobs are stored in 4Mb chunks, compressed, and there’s an option to store them on the filesystem (or SQL Server FILESTREAM fields).

Cross-links are the way to link together different repositories, potentially creating a hierarchy of components shared among different projects. An Xlink is a special directory entry that points to a given changeset on a different repository (potentially on a different server). The contents of the Xlink will be transparently downloaded to the user workspace. There are read-only Xlinks which are meant to handle dependencies that rarely change, and writable Xlinks to handle parallel development across a codebase made of several repositories. Branching and merging is handled by Plastic on writable Xlinks.

By default Plastic stores every repository on a different database. Submodules allow admins to store several repositories inside the same physical database which is useful both for database administration and to create repository namespaces in organizations with hundreds of repositories. Submodule repository names look like “graphics/opengl” and “graphics/directx” instead of just the single name given to a repo.

Transparent SCM
You can program using your favorite IDE/editor and Plastic will detect the changes you’ve done. You change a file and Plastic detects it. You move a file, a directory and Plastic also detects the move, perfectly tracking it even when the file was changed. This is what we call transparent scm and basically allows you to forget about the version control until you have to checkin and them Plastic will do its part, detecting even complex changes.

Client changelists
This features helps you to organize the pending changes (to be checked-in) in your workspace with user defined categories. One of the goals is to make the Perforce users feel at home.

Exclusive checkout (locking)
There are files that can’t be easily merged or even merged at all, like images, animations, simulation data, 3D files and many more. Using Plastic you’ll be able to simply exclusive checkout (lock) these files to avoid them to be modified concurrently. This is key for many industries, like game development.

Security
Being able to set permissions to repositories, branches, labels, paths is not only good to secure the codebase but also to enforce policies and best practices like “don’t directly checkin to the release branch”.

Fine grained security with Access Control Lists (ACL)
Using Plastic you can set permissions to branches, labels, repositories, paths and even the server itself. Objects inherit in a hierarchical way (repository inherits from server, branch from its repo) so it is possible to configure very fine grained and flexible security policies. There is a list of more than 30 version control specific permissions like add, change, move, checkin, mergefrom, applylabel and more.

Path based security
You can set permissions (ACLs) to specific paths so that they’re always checked before performing certain operations. For instance, it is possible to deny the “ci” and “add” permissions at “/build/ scripts” for everyone except the “makefile masters” so that nobody messes with the build scripts. Path based permissions introduce a number of new possibilities together with the regular object ACLs.

Active Directory, LDAP and other authentication systems
Companies can integrate Plastic with their Windows Active Directory or LDAP system so that users, groups and authentications are handled by the operating system and not by Plastic. This way there is no need to import users periodically and any change in group assignments will be immediately detected by Plastic. Built-in user/password is also available for groups that don’t use LDAP/AD or need to be independent from the IT department.

SSL
Every Plastic server listens by default on a single TCP port, which makes it easy to configure and secure. It can be configured to listen on more ports including SSL, thus securing the communication between clients and servers or between different servers during replica.

Integrations
Version control is a cornerstone tool in the software development process and as such many other tools extract data and interact with it.

IDEs
Developers using Visual Studio can take advantage of the “VS Package” included in the Plastic installer. Inside the IDE you can checkin, checkout, branch, merge, show the Branch Explorer and basically do everything the GUI can do. We support all versions back from the SCC days till the newest Visual Studio 2013. The VS plugin includes unique features like "semantic history".

Issue tracking and project management tools
Teams embracing agile will most likely be working with Rally, VersionOne or JIRA. They are fully supported and also Bugzilla, Mantis, Trac, OnTime and FogBugZ. Redmine, YouTrack and ALMs like Polarion are also supported. Adding a new one is not hard, so do not hesitate to contact us, even if it is a in-house one.

Visual Studio 2017 support
Eclipse programmers will use the Repository Provider that implements the key version control capabilities integrated in the IDE. We recently added a Java based Branch Explorer too. We support up to Eclipse 4.4 Luna.
Plastic is well-known to work great with PowerBuilder and other IDEs compatible with SCC including MatLab.
Plastic also works with IDEs compatible with the newer VS Package system like Atmel Studio.
Same holds true for Eclipse-based IDEs such as LPCXpresso and Eclipse RCP.
IntelliJ and Android Studio developers also have a native Java plugin to perform the most common version control operations.

Developers using any other IDE can take advantage of transparent scm which basically detects any changes in your workspace included files and directories being moved and renamed. It means you can simply work in your preferred editor and then switch to Plastic “pending changes” view, find the changes and checkin.

Microsoft Office (Word and Excel)
You can use the Office plugin to checkin, checkout and view the history of files while working inside Word and Excel. Word diff and merge (invoking MSWord as diff and merge tool) is also available out of the box.

Windows Explorer integration
If you ever used TortoiseSVN (or any other Tortoise*), chances are you miss performing checkouts, checkins and even merges from the Windows Explorer. The Plastic installer includes a Shell Extension (or Explorer integration) that basically is able to perform the same operations as the GUI but all available as a context menu on the Windows Explorer.

Continuous Integration (CI) and DevOps
You can integrate Plastic with a variety of tools inside your build and deploy ecosystem. Plastic can be integrated with Jenkins/Hudson, JetBrains TeamCity, FinalBuilder, CruiseControl, Atlassian Bamboo. You can also integrate Maven using the Plastic SCM plugin.

Issue tracking and project management tools
Teams embracing agile will most likely be working with Rally, VersionOne or JIRA. They are fully supported and also Bugzilla, Mantis, Trac, OnTime and FogBugZ. Redmine, YouTrack and ALMs like Polarion are also supported. Adding a new one is not hard, so do not hesitate to contact us, even if it is a in-house one.

Sync with other version control systems
You’ll be able to keep Plastic repositories in sync with Git and Perforce and also import and export

This is how we called the bi-directional synchronization between Plastic and Git. Basically Plastic can talk the Git network protocol and then push and pull packages to a remote Git server. From the Git side it is pretty transparent since Plastic totally adheres to the protocol, so the remote Git server *thinks* it is talking to a regular Git process. Using GitSync you can push merges from Plastic to Git (and viceversa) and they’ll be perfectly valid.

The great thing about it is that it is not a “migration solution” that only keeps a single branch in sync, you can basically do things like use the Plastic GUI as a Git client and interact cleanly with other team members using Git. Plastic internal structure is close enough to Git’s that it is totally possible to exchange all commits (changesets in Plastic jargon), branches and merges between them.

Multiplatform
Plastic SCM is a multiplatform version control system. You can run client and servers on Windows, Linux and Mac OS X, and there are also solutions for other Unix platforms.



Only for V.I.P