Transparent SCM Code more and do less version control


How does Plastic SCM looks

How does it look?

You just change your code files, create new ones, copy move, rename, delete... From any tool, from your IDE to the command line. No integration to setup.

Now, when you are happy with your changes, check in everything with a single click. Plastic SCM detects all the actions you did and displays them together so you can quickly check them in and get back to coding.

Tracking all these changes helps later to have a smooth merging experience, so you can enjoy the benefits of branching with no restrictions.

How does Plastic SCM looks


The idea is that you spend more time thinking, coding or doing your stuff and less with the version control tool.


When you refactor code, you often end up moving classes to different places and this normally means renaming and moving files.

And at the same time, those class files normally have some changes inside. Plastic SCM has a similarity detection algorithm that identifies when a file has been moved to a different location and has changes inside.

The file has been moved and then changed

Moved directories

Moved and renamed directories are detected as such. It means that if you rename or move a directory, Plastic SCM identifies it and displays only the directory as moved, instead of printing all files inside as moved.

Integrated diffs

Plastic SCM has a robust capability for detecting, displaying, and comparing moved blocks. It is called Xdiff.

You can adjust the parameters used by the Xdiff capability to configure our moved code detection.

Undo changes

If you are not happy with some change you made, you can easily undo it: mark the files you want back and click "Undo changes". Moved or deleted files are also restored with one click!

No integrations needed anymore

Since Plastic SCM now detects every possible change you make on the files and directories, you can seamlessly use it with any tool even if no full-fledged integration exists.

What if the moved file is too different?

If you made a lot of changes in the moved file then the similarity matching algorithm will fail to detect the move. The file will show up as deleted in the source directory, and private (added) in the destination.

You can manually "match" these two and tell Plastic SCM that the file is actually moved instead of deleted + added, cleanly preserving its history.

Checking out for high performance

If your workspace is very large (hundreds of thousands of files), scanning every directory for changes can take some time (specially if the disk cache is busy with compilations or things like that).

To avoid delays scanning the disk for changes, check out files when they are modified. Then, the pending changes view can be setup to show only checkouts instead of scanning the disk for changes. This solution is a lot faster and greatly helps in scenarios with many files. Related features Visual Studio Integration


Get the latest news