There’s a New Version Control in IntelliJ Town: Plastic SCM

This is a guest blog post from Jordi Mon Companys, Product Manager at Códice Software

Context switching is one of the biggest hurdles developers need to overcome when in deep work mode. We also know that all of JetBrains IDEs – IntelliJ IDEA for one – are used across the world. In fact, IntelliJ IDEA is the world’s most used Java IDE. So, if these two things are correct, and we want Java programmers to benefit from versatile and powerful semantic version control, what should we do?

image4
Presenting Plastic SCM’s integration in IntelliJ IDEA

Plastic is a versatile (Centralized and Distributed), full stack (includes CLI, cross-platform GUIs and even a standalone GUI for non-devs), and powered with a merge machine that can be upgraded with semantic superpowers.

With this integration, we are providing all IntelliJ IDEA users with the ability to manage Plastic from within their interface.

Modern version control for Java devs

Version control has evolved throughout time considerably. Modern version control is able to manage huge repos and massive files without hiccups. It is also able to automate build workflows and integrate with your modern CI and CD pipeline.

Modern version control is also about visualizing complex code bases, its history and contributors. But most importantly, modern version control is about the productivity of Product teams. Product teams are now the key element in software companies, if not all companies. Product teams work fast and ship constantly. They work with code and binaries and build features made up of tasks. This is what Plastic is all about: shipping features one task at a time.

You can now create repos, manage them, create branches, collaborate, diff and merge branches, and connect build processes that work all without leaving IntelliJ IDEA. Let’s see what all these different things look like.

First, select Plastic from among IntelliJ IDEA’s checkout options:

image1

Select your repo:

image8

Select the branch you want to work on:

image10

And select the label you’ll need to work with:
image6

Finally, let IntelliJ IDEA know from which workspace you will check in your changes in the Java code.

image7

The summary windows before you get on with coding would look like this:

image11

Welcome to IntelliJ IDEA’s new working version control system:

image2

If you want to understand first the history of the project you’ve just joined, go to the history pane:

image3

Ready to commit some changes to the code base? The check-in dialog box in IntelliJ IDEA is now invoking Plastic’s check-in functionality to do so:

image5

Plastic’s IntelliJ IDEA plugin

In the following weeks, you will find the plugin available to download and use in the JetBrains Plugin Marketplace, where the TeamCity plugin is right now. For the time being, we suggest two methods for installing the plugin that are explained in this blog post.

image9

We are making Plastic compatible with all IntelliJ-based IDEs, which are best of breed. We are very happy to provide this plugin for all IntelliJ IDEA users, and we look forward to hearing from you all and making your context switches minimal! We want to help you focus on your work in IntelliJ IDEA, to keep your eyes only on the Java code you are working on, and to have all the advanced features and products at your fingertips. Never stop shipping, one task at a time!

About Zlata Kalyuzhnaya

IntelliJ IDEA Marketing Manager at JetBrains. twitter: @ZlataKalyuzhnay ‏
This entry was posted in Guest Post. Bookmark the permalink.

6 Responses to There’s a New Version Control in IntelliJ Town: Plastic SCM

  1. jl says:

    To be honest, (www.plasticscm.com’s) Plastic vs Git comparison is completely wrong.
    Git has great GUI tools. Git has great 3-way merge tools (including IntelliJ!). Git works fine with big files (did they hear about LFS?). Git can handle task branches (git-flow). Git can preview merges (via great tools like IJ, SmartGit, GitKraken). And the last one: “You can reach the engineers” -> with Git, we can reach 1.000.000 developers on StackOverflow, and follow the famous “it Flight Rules” on GitHub.
    And Git is free 😉
    Why should we use a new tool that is not free, not mature, with no established community, and doesn’t offer extra-features?

    • Helbrass says:

      I am sorry jl, your comment really makes me wonder how old are you. Why cannot you just be happy that there is one more tool on the market that tries to be better, that has good tooling and good integration with IntelliJ, and that specifically addresses the points that lots and lots of developers find painful? I would be thrilled if my company allowed us a choice, I would gladly give other tools a chance! While the popularity of git seems to be mostly due to fanboys like you and wide-spread catch 22.

      • FS says:

        I’m sorry – jl is right.
        And this doesn’t depend an fanboy question but on most reasonable questions and statements.
        This “feature matrix” on the companys home page is inccorect and subjective and he just mentioned that.

        For example the main developer is not Linus Torvalds anymore but Junio Hamano but this doesn’t matter – you have a develper mailing list which you can interact direct with the developers – at a company this ist mostly not (given) – you interact with the sales.
        And the second fact is that there ist huge community behind git with a lot of resources for learning (youtube videos, free ebooks, blogs and online turorials) and support (eg. stack overflow).
        And the third fact is that git is open source – so when you are think a featur is missing you can commuinacte this with the developers (refer point 1) or make a fork and do this your own and provide a merge request.
        And I gues that theres a lot more people working on the git source code (github says round about 1300 contributors), not counting the people which provide tools like guis shell extensions and ide integrations.

        This discussion reminds a little bit about the linux windowmanager discussion, just take a look about this many kde and gnome forks which mostly bod down after the first enthusiasm is gone.
        So why don’t we give this guys a change to provide this improvements into git instead of cooking their own soap ;-)?

  2. Jon says:

    Version control is a solved problem. Thank you Linus. As devs we should be focused on making real progress, not slightly improving an existing tech that works great.

    • Tagir Valeev says:

      Well I’m not quite sure. Git (as well as all classic VCS) approach has some unresolved problems, e.g. dealing with merges. We see merge conflicts, we accept this pain, we think that it’s the necessary evil. But there are new ideas to address such issues: see the Pijul VCS. Of course currently it’s small, lacks tool support and community, but it looks promising. Probably in ten years Git won’t be the default VCS choice. In general it’s good to explore problems which look solved, because who knows, probably better solution exists.

    • Joe says:

      Solved? When git lets me create a branch from a branch and then merge both branches cleanly, let me know. This is a simple use case that even Subversion handles without a problem.

Leave a Reply

Your email address will not be published. Required fields are marked *