Who we are

We are the developers of Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.

If you want to give it a try, download it from here.

We also code SemanticMerge, and the gmaster Git 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.
  • 16 comments:

    1. Linux? I guess you meant Linus :)

      ReplyDelete
    2. Can I assume that this is the answer to an e-mail I sent to Pablo some weeks ago? :PPPP

      This is actually a GOOD JOB!

      ReplyDelete
    3. You might start getting traction selling your GUI on top of Git directly... not sure what happens to the server component then though.

      Good luck guys as you figure all this out business-side wise! The tech certainly seems solid

      ReplyDelete
    4. @cidico: no, no, this is not the same as any kind of hosted site. I share some thoughts about it on twitter (in Spanish) from my @psluaces private account, but this is certainly something different.

      ReplyDelete
    5. @anonymous: our goal right now is not developing a GUI just on top, but actually a sync mechanism to let plastic operate with git-upload-pack process and do something similar to what git-send-pack does, from our side, hence avoiding the need to have a local git repos.

      From the customer side, you'd be "deploying" to GitHub, but you'd be able to do all this and still taking advantage of all the plastic's extra powers.

      ReplyDelete
    6. I would love to se Hg there as well. I would be perfect for us to get a real feel for plastic this way instead of doing a fullblown conversion at the start.

      ReplyDelete
    7. Yeah, well, since Hg supports fast-import/export too (AFAIK), I think it would work out of the box, wouldn't it?

      ReplyDelete
    8. It would be easy to test against bitbucket as well, they support both hg and git. I havent found any good information how to use Fast-import directly from hg

      //Daniel

      ReplyDelete
    9. Can you add a sample of the config file? The documentation is rather sparse on PlasticGitSyncTray.exe.config and by default the trayicon fails to start.

      ReplyDelete
    10. @wvd_vegt still having the issue? If so let me know and we'll get it ironed out.

      ReplyDelete
    11. I'm with @wvd_vegt about the config file. I know it's a .NET/Mono config file, but it would be nice to at least have comments in the file explaining what each setting does and how to set it appropriately.

      ReplyDelete
    12. Sorry, it may have helped if I had read the README file. ^_^

      ReplyDelete
    13. I would recommend adding quotation marks around the values of all settings. I have git installed in the Program Files directory, but I don't have the bin directory in the Path environment variable. I used the Git for Windows installer.

      ReplyDelete
    14. Check our GitSync instead, it is much more advanced than this now

      Stash is just standard git, isn't it? Did atlassian add any code to git?

      ReplyDelete