Using Plastic SCM as GitHub client

Using Plastic SCM as GitHub client

Wednesday, April 04, 2012 Ma Nu 16 Comments

Do you remember the blog post explaining how to connect to GitHub? The process was a little bit confusing, since you had to manually specify the mark files locations and then type every single git and Plastic command. Well, we needed something better.

The problem to solve

Some developers teams are constricted by tight release times and they are not able to spend time trying new applications.

For example, some tons of developers are using GitHub on a daily basis. GitHub is easy, modern, cooooool... it has everything a web 2.0 app needs, but then you go and clone your git repo and you start working alone with git and... is time to freak out!

You can probably argue, but for many git is difficult to learn, and not so easy to use... as a dark hacker tool born to version THE kernel itself :P.

Github project site

Plastic to the rescue...

Ok, here's the deal: you can use Plastic SCM as a GitHub front-end.

You just need to install plastic and the new tray application into your machine: it will take 2 minutes or less.

Now you'll get the full plastic UI instead of the git CLI. Unless you're a hard-core hacker (do you use vi?) you will be able to do everything using a beautiful, modern and powerful user interface (it takes some time to develop it, you know? We need to stress how good it is ;P)

Using Plastic SCM as a GitHub front-end requires a synchronization procedure.

It's perfectly doable with the fast-export/fast-import commands but it's a little bit tricky, so we have created a little tray application to keep the GitHub and plastic changes  in sync.

You won't need more command line hacker stuff, just a tiny tray application with two options, pull changes and push changes.

See how it feels:

Sync tray application

What you get

You get the awesome Plastic SCM UI!

Check more here.

The workflow

Ok, so you have your shiny GitHub repository in the cloud, and its network diagram looks like this:

Github network diagram

It's not the best diagram representation in the world but that's what you get ;)...

Okay, now, let's pull the nice GitHub repo into plastic:

Go to the "tray app"

Select the "Pull Git changes" option

Pull Git changes from Github

In a few seconds (ok, unless you're downloading a huge project, then it will take longer) you will be able to have your git repository inside Plastic SCM.

Check how it looks like

I think this diagram is much better than the GitHub one, but I'm obviously biased.

Did I say it is interactive?

Now, let's change something and checking to the master branch using plastic:

You will create a new changeset (plastic jargon for git commits) and

Using the "Push Plastic SCM changes" menu option you will be able to push the new changeset into git and then GitHub.

Let's see how it looks like after the push operation in both systems:

New change inside Plastic SCM

New change inside Github

And you just made with a mouse click!! :P

Push Plastic SCM changes to Github

If the changes are done in the GitHub side you only need to select the "Pull Git changes" option and the new changes will be imported into Plastic SCM and will be ready to be used.

How it works

Pull Git changes: the tray application first checks if the marks files exists. If not, a new pair of marks files will be created for you, then a "git pull origin" command is executed in order to get the latest changes from GitHub. When everything its downloaded the tray application creates a new fast-export package using the marks files. Once the fast-export is created, it's imported by Plastic using a fast-import command.

Push Plastic SCM changes: as you can imagine the process is now in the opposite direction. First a plastic fast-export package is created, this package is fast-imported into Git and finally pushed into GitHub running a "git push origin".

The marks files are used by the fast-export and fast-import commands, it's a easy way to perform incremental synchronizations.

By default if you run a "git push origin" or a "git pull origin" git is going to use your working branch, for example "master", but we do need to change it, we want a full synchronization so we have to do this.

Download

You can find the source code and binaries HERE. You are able to modify, fix, break, debug, improve, blend and burn the code as you want.

What's next?

We're working on a bi-directional sync layer that will be compatible with Subversion, TFS and Git, and then also ClearCase and Perforce.

The goal is to make it easier for teams to transition to Plastic SCM while they still co-operate with other groups using CC, p4, git, svn or whatever they use.

Since 2008, and basically thanks to GitHub, every major open source project migrated away from Subversion to Git. SVN used to be the big guy in town, and it is now languishing: LinuS himself said you must be brain-dead to use SVN. Well, we can't afford saying that, but it is obvious there's no point today to consider SVN with hg, git and... plastic out there!!

Hence, all major OSS projects already jumped to DVCS, and our vision since we started Plastic SCM back in 2005 is that enterprises will be next: and that's where we want to be. Plastic is designed from the ground up for teams developing commercial software.

The thing is that we need quite some interop with other version controls, and that's why we implemented fast-import/export support in 4.0 and why we're so interested in making Plastic work with cloud repos like GitHub.

Right now, what you've here, is just a tiny script wrap, but we're working on on something much more powerful.

The current tray-app uses an intermediate git repo on your machine, but we're working on an alternative that uses the git protocol directly, to communicate without the need of an intermediate copy. Not the easiest job, but really exciting.

So, expect quite some good interop in the coming months... and use Plastic! :P

Manuel Lucio

I'm in charge of the Customer Support area.
I deal with complex setups, policies and working methodologies on a daily basis.
Prior to taking full responsibility of support, I worked as software engineer. I have been in charge of load testing for quite some time, so if you want to know how well Plastic compares to SVN or P4 under a really heavy load, I'm your guy.
I like to play with Arduino GPS devices, mountain biking and playing tennis.
You can find me hooked to my iPhone, skate-boarding or learning Korean... and also here @mrcatacroquer.