Here is something pretty amazing. Plastic can merge methods that were moved across files.

I'm going to move a C# method to a different file in a branch.

In a different branch, I'm going to modify the original method.

Plastic merges this without human interaction and applies the change correctly in the new file.

Ta-da!

We are working on a new code review system. Yes, I know this is the kind of blogpost that will quickly get out of date, but I felt the urge to share with you, dear Plastic user, what we are working on.

I'm going to share what we are doing, what you can expect, how it is going to be better than any pull request system to date, why it took us so long to get started, and how code reviews are central to our version control vision.

Just to give you an overview of what it will look like, let me share a screenshot of one of the design docs:

One common workflow in other version controls such as Git is as follows: you create your bugfix or feature branch, and once you are finished with it and your changes get integrated, you delete it. Plastic SCM, for traceability reasons, does not support deleting branches. Because branches are the central part of our development philosophy, both the core and the GUIs can handle hundreds of thousands of them without a problem. (Our main repo has almost 25K branches right now, and that's actually very few!) So, you don't have to delete them for performance reasons.

But, you can "archive" branches you no longer need to reduce the clutter, and even to adapt your workflow from your previous SCM tool if you are unfamiliar with Plastic SCM. Let me show you how!

If you pay attention to the release notes, you probably know that Plastic's command line client now has a clone command. If you are used to other version control tools, then using it will be as easy as falling off a log. If not, let me tell you what the cm clone command does—it creates an exact copy of a remote repository in your Plastic SCM server.

You just need to type in the remote repository specification, and the cm will take care of creating a local repository of the same name (if it doesn't exist yet) and replicating all the content from one to the other.

The syntax of the cm clone command is as follows:

> cm clone <src_rep>@<src_rep_server> [dst_rep_server]
cm clone has some more advanced options that you can learn about by calling cm help clone.

For example:

> cm clone codice@central.home:9095 codice@co-located.home:8084

If you don't specify the destination server, the clone command will use your default server.

I know what you're thinking. What if I don't have a direct Internet connection between source and destination? No problem. You can clone to a package! Let me show you how:

Life is easy when everything is at the reach of your hand. That is why we decided to make Plastic SCM fully integrated with all IntelliJ IDEs! Yes, you read it well, with all 12 IntelliJ Products. Those include IntelliJ IDEA, PyCharm, PhpStorm, WebStorm, RubyMine, AppCode, CLion, GoLand, DataGrip, Rider, MPS and Android Studio. The updated plug-in is compatible with versions 2019.x, 2018.x, 2017.x and 2016.x of all the IntelliJ Platform products and will soon be compatible with previous versions, stay tuned.

JetBrains IntelliJ Products are fantastic development environments. One of Plastic's main goals is to prevent the loss of focus so, if you decide to work on any of Jetbrains' IDEs then, we will bring Plastic functionality there: all of Plastic's functionality can be invoked from the preferred interface.

By default, Gluon groups changesets by the Creation Date. It's neat—that way you have your changesets grouped in friendly time frames ("yesterday", "last week"...).

But, the changesets view supports even more advance grouping and filtering. Let me show you!

Command Line tools are always a challenge. We decided to simplify and make Plastic's CLI more intuitive and user-friendly and at the same time keep consistency of commands and functionality across the product's different GUIs. You shouldn't be scratching your head to a) know how a command expression is built or b) find specific help.

The main lines of action were the following:

  • Human readable command input and output
  • Enhanced discoverability and help
  • Command expression consistency

Following these principles, we decided to move on and continue upgrading our CLI like crazy lately.