Plastic SCM offers tons and tons of features that make a developer's life much easier.
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.
You'll be able to diff refactored code with the new built-in semantic diff plus the "analyze refactors" feature. It can find refactored code across files for C#/Vb.net, Java and C.
The built-in 3-way merge tool Xdiff/Xmerge lets you resolve even the most complex merge conflicts since it features language-agnostic refactoring support. Plastic includes our SemanticMerge product. This means that you get the extra power of code-aware merges if you need full semantic merge capabilities.
Since an image is worth a thousand words, you can visualize the merges using the Branch Explorer .
Item merge tracking helps you to understand merges when running diffs, annotates and displaying the 2D version history of a file .
One of the key reasons why teams move to Plastic is its ability to work in distributed mode . Distant offices can be seamlessly connected, developers can work from home and you'll still be able to scale up to handle hundreds of developers working onsite. For more details, see the Plastic SCM book .
Using Plastic, a developer can have a clone of the repository on their local machine and checkin, branch and merge without connection to the main server. This is what fully distributed is all 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 a rendezvous point.
It is very common to have teams working in different cities, sometimes even on different continents. They work on a shared codebase, so it is a good idea to have a server at each site, and replicate changes between servers.
If the server is only at one of the sites then all the others will suffer from slow responses, even if they use some sort of proxy server (which used to be the solution in the old days). Plastic applies the distributed technology to enable teams to get the best out of distributed (connect servers) + centralized (developers working at each site checkin locally) approaches.
Some teams need to benefit from the powerful branching and merging of DVCS but don't want to have a clone of the repository (or repositories) on each machine.
Using Plastic, you can do both distributed (checkin-push workflow) and centralized (just checkin to the central, old Subversion style). Some team members can work centralized while others use a distributed setup concurrently.
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 operation from the GUI, which is pretty easy to learn. User experience is our most important goal.
The Branch Explorer is the core feature of the GUI. It is an interactive graphic that renders the evolution of the repository. From the Branch Explorer view you can branch, merge, diff, push and pull and switch to different branches. If there is only a single feature that makes Plastic worth it, this is the Branch Explorer. Find out more here.
Plastic includes 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. Read more about the Code Review system .
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. Check the GUI guide for details .
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 view 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 our
SemanticMerge
product. This means if you are merging C#, Java, VB.NET, or any other language
supported by SemanticMerge, you get the extra power of code-aware merges.
Plastic also includes its own 3-way merge tool called Xmerge.
Besides being a regular merge tool, it can track and merge moved code fragments.
Plastic also lets you plug in any other 3-way merge tool like Araxis, BeyondCompare,
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 shows changed, added, deleted, moved and files that have been merged in the changesets, labels or branches you're diffing.
Plastic includes an image diff tool, able to compare two revisions of the same graphics file. The file can be in a variety of file formats (especially if you have ImageMagick installed). This tool can show images side by side, do an "onion skin" preview, calculate differences, do a "swipe" and diff the image properties in text format. More details in the GUI guide .
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 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.
Plastic Gluon is the version control designed and crafted for artists in game development.
Now displays directory sizes to better control what is downloaded.
6.0 comes with a new repository storage. It is super-fast and scalable, and it has been designed specifically to deal with the way in which Plastic handles data and metadata read and writes. As a special purpose storage, it is hard to beat in terms of efficiency.
We created support for 2 different workloads in Jet:
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 that you go through the history of a file you are 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 can find the method even when it has been moved, renamed or heavily modified throughout its history.
You can use this feature both from the GUI and the Visual Studio Package . It can track methods, properties, constructors, members and more.
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:
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.
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.
Big blobs (configurable size) can be stored in the filesystem instead of the database for storage optimization and performance.
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.
Although Plastic is a full featured DVCS capable of replication, 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-sites but for high demand, heavy load scenarios where reducing data traffic on certain network segments can greatly improve overall network performance. Check out this blogpost for more details .
A standard Plastic update (download files to the workspace) walks the entire directory tree looking for changes. It is very efficient, but teams with very large codebases (greater than 500,000 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.
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:
Teams with servers in 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 out more here .
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.
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 efficient 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 in the filesystem (or SQL Server FILESTREAM fields).
Full test suite - pass an entire unit + smoke test cycle - This means thousands of unit tests and hours of automated command line testing every release.
Performance tested - ready for super fast single user access. Fast checkin/update cycle.
Tested under heavy load - This means it has been tested and tuned to handle hundreds of concurrent users as described here.
* SQL Server CE - perf - slower than sqlite
Reduces network footprint and enables backwards compatibility: 6.0 is now compatible with all versions since 5.0.
You can use and develop shared components in Plastic using Xlinks and submodules.
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. Check out the Xlinks guide.
By default, Plastic stores every repository in 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. Learn how to create submodules.
Note: if you're familiar with Git modules, then Xlinks are like merge-aware Git modules.
There are several features that help you on a daily basis when you're working with Plastic:
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 must checkin and then Plastic will do its part, detecting even complex changes. Find out more here.
This feature 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. Check the guide for more info .
You can "shelve" changes in Plastic and keep them saved in the server (not checkedin) until you apply them later. You can shelve several files together and give them a description. They'll be applied using merge, so it is a good way to apply changes to a different branch. Find out more in the GUI guide .
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 exclusively checkout (lock) these files to avoid concurrent modification. This is key for many industries, like game development.
You can create your own metadata in the form of name/value pairs, attaching them to any object in the repository. This enables you to create sophisticated reports, using data retrieved by SQL queries. Check out the Find guide . Later, you'll be able to see the attributes in the GUI in places like the branches list, the Branch Explorer and more.
Sometimes you need to apply some transformations to your working copy that you don't want to checkin. For instance, you need the "/extlibs/includes" to show up inside "/includes/extlibs" in your local copy. All this, and a lot more, can be achieved with "transformable workspaces".
Cloaking rules (defining cloaked.conf) lets you avoid some paths (files or directories) to be updated or downloaded at all. Now with simpler rules you can define flexible rules to include or exclude certain paths.
Now the Branch Explorer can be globally configured for all users .
Heavily improved filter performance (cloaked, ignored, etc.)
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".
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 finely 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. Learn more here.
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 several new possibilities together with the regular object ACLs. Check out the Security guide.
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.
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 replication.
Plastic keeps a configurable audit trail that register all important events happening in the system. Check out this article to find out how to comply with Sarbanes Oxley.
This feature enables teams to use public servers because data will be stored in an encrypted way so that even if the server is compromised the attacker won't be able to access the original files. The mechanism is simple: you configure your team (or local) server to encrypt any file data being transferred to a given external server. It will also be decrypted while receiving from the encrypted server. The key will only be stored on your machine so unless it is compromised the data will be secured on external servers.
Version control is a cornerstone tool in the software development process and as such many other tools extract data and interact with it.
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 2019. The VS plugin includes unique features such as "semantic history".
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. The 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. Our IDEA plugin supports up to IntelliJ IDEA 2019.x.
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. This means that you can simply work in your preferred editor and then switch to Plastic "pending changes" view, find the changes and checkin.
Teams embracing agile will most likely be working with Rally, VersionOne or JIRA. They are fully supported as well as 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 an in-house one.
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.
Better CI's functionalities
Heavily improved TeamCity, Bamboo and Jenkins (pipeline support).
GoCD support
Now GoCD, the continuous delivery server, works with Plastic SCM.
Code reviews are key in "task-oriented development" and as such you'll be able to use Atlassian Crucible integrated with Plastic. Plastic includes its own integrated code review system too, which you can use from the GUI or the WebUI.
If you develop with Unity, you can use the Plastic integration with Unity.
Office 2016 support
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.
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 can perform the same operations as the GUI but is available as a context menu in the Windows Explorer.
You'll be able to keep Plastic repositories in sync with Git and Perforce and also import and export using the fast-import/export de-facto standard.
This is what 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 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 in reverse) and they'll be perfectly valid.
The great thing about this 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's 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.
P4Sync is a bidirectional synchronization with Perforce to help teams using P4 migrate to Plastic.
Since big migrations are complex and sometimes big organizations move team by team to Plastic, there's a period when there are developers already in Plastic and developers still in P4. But development can't stop, so we created a way to keep a P4 branch fully synced with a Plastic branch. This is P4Sync. P4 and Plastic are structurally different so only one branch can be kept in sync. This is clearly a solution designed only to help during the transition phase.
TFSSync is a bidirectional synchronization with Team Foundation Server to help teams moving away from TFS during the transition phase.
Like P4Sync, it can only keep a single branch in sync between the two systems and it is specifically designed to help during migrations.
Plastic can import any version control history using the fast-import format, which is the de-facto standard created by Git. Anything that can be imported into Git can therefore be imported into Plastic.
We have helped customers to migrate from Hg, Subversion, CVS and others using this method.
Plastic is also capable of exporting to fast-export format (besides GitSync!) which basically means that if you ever need to move away from Plastic, you're free to go.
Learn more about the fast-import/export operations .
Plastic SCM is a multiplatform version control system. You can run client and servers on Windows, Linux and macOS, and there are also solutions for other Unix platforms.
All Windows versions are supported, including Windows 7, 8 and all server variants. In fact, we preserve an ancient W2K server to run GUI and CLI tests daily. You can find all the available installers and bundles on our downloads page.
You can install Plastic servers and clients (including the GUI) on different Linux flavors. We have packages for the most common distros.
Mac OS 10.7 and higher are fully supported to run both clients (including the GUI) and servers. View more.
We discontinued support for PPC based processors long ago.
While we don't provide official packages for OpenBSD or FreeBSD, we have tested Plastic on both OSs. You can install it taking advantage of the ZIP packages that include the binaries in a platform agnostic way.
Clients and servers are optimized for 64bits hardware so you can take advantage of installations with large memory configurations. The Plastic server is multi-threaded to take advantage of multiple cores and processors.
The client also takes advantage of multicore to upload and download data in parallel.
It is a Java based Command Line Client (CLI) that is cross-compiled from our regular CLI source code. Teams that need to deploy to HP-UX, Solaris or other Unix flavors use JavaCLI to automate commands on those platforms.
As expected, it is straightforward to connect clients and servers running on different operating systems and even using different authentication methods like a Linux client connected to a Windows Plastic server using Active Directory. The data transfer works between hardware with different endpoints.
Usability improvements, built-in SemanticDiff, merge explanation diagram, Branch Explorer filters plus several changes to create a smother experience.