Direct push/pull from Plastic SCM to Git

Direct push/pull from Plastic SCM to Git

Thursday, October 18, 2012 Pablo Santos git 14 Comments

Plastic SCM is now able to speak git protocol language! What does it mean? Basically, Plastic now can push and pull directly to remote git servers using both native git and https protocols, which includes well-known sites such as github, BitKeeper, codeplex and many others!

The problem

When we started developing the git-bidirectional synchronization with Plastic SCM we had the following scenarios in mind:

• Developers already using Plastic SCM who want to contribute to projects in sites like github, codeplex, BitKeeper and others.
• Developers working on teams using Git as primary server who prefer to use Plastic SCM but need to contribute changes back to the main server.
• Teams gradually adopting Plastic SCM who need to contribute to other teams on Git.

The solution

We went the hard way: we didn’t come up with some sort of intermediate script to convert changes from one system to the other, imposing a ton of limitations (you might have read of solutions like this during the last weeks, from other vendors :P), but we actually implemented the git network protocols in Plastic, so it can directly pull and push to git.

Plastic will start a negotiation phase with the remote git server, as a git command would do, speaking the same protocol described here. It is a core feature, not an add-on script.

Pulling changes from git

And it is really simple to use, all you need to “pull” changes from a remote git server is the following:

cm sync textmate git https://github.com/textmate/textmate.git

Assuming the local “textmate” repo is empty, it will calculate the changesets and branches it needs to pull from the remote github repo, and will pull them.

In order to pull new changes done at the github side, you’ll simply re-run the same command:

cm sync textmate git https://github.com/textmate/textmate.git

And it will now calculate and pull only the new changes made at the git side, if any.

Pushing changes to git

The same command is capable of calculating what’s new at the Plastic SCM side, negotiate with the remote server and push the changes.

The unique value

There are actually two things to consider:

• For Windows developers contributing to projects on GitHub, BitBucket, CodePlex and so on: we give you a fully featured DVCS, designed for Windows users, with all the GUI features you can imagine, and ready to push your changes back to Git.
• For current Plastic SCM developers: a way to interoperate with external Git repos, if that’s a concern for you.

Feature list

The capabilities of the current beta that we will be announcing on the coming days are:

• Full push/pull to remote git servers, including all commits, comments, branches, merge tracking and tags.
• Conflict management: it is possible to make changes on the same branch on the git and Plastic sides concurrently and Plastic will be able to handle the situation, pull the changes, request the user to run a merge, then push the solved conflict (as you’d do if you just were using a full git setup).
• No limits on adding/deleting or moving files at any of the two sides.
• Full merge tracking: you can merge at git side and Plastic will recognize the merge tracking, and the same is true in the Plastic to git direction. That’s the benefit of Plastic SCM and git being full DVCS! :)

How it works

Since an image is worth a thousand words, let’s go, step by step, through an entire push and pull process:

The image above shows the initial scenario: you’ve a git repo and then you pull it on Plastic. As a result you get an exact clone with the branches and commits you had in Git now converted to Plastic, and what’s best, able to be rendered in the branch explorer!

The next image shows what happens when a new commit is created on the Git side, and how the “pull” from Plastic SCM will retrieve it. Instead of just performing a simple change, the figure shows a merge from “big_feature” branch into “master”. The result in Plastic SCM mimics what happened at the Git side, adding the merge link (which is rendered as a “green line”) on the Plastic branch explorer.

The next step is performing a change in Plastic SCM and pushing the change to Git. In order to create a more complete example, instead of just creating a new changeset, we will also perform a merge.

The changesets “6” and “7” are created on the Plastic side then they’re pushed to Git. As you can see on the figure below, the merge information (multiple parents on the git repo) is also sent from Plastic to Git.

So far the changes were done at one side or the other, but not at the two sides concurrently. The following picture shows what happens when developers work on the same branch at the same time.

One new commit is created in git (on green) and a new one in Plastic (orange).

If now the Plastic developer tries to “push” to Git, an error will show up since there are conflicting changes (same that would happen on a similar scenario on a pure Plastic or pure Git setup). The steps to follow are:

• First push the changes from Git
• A new “subbranch” will be created placing the “88ffa” changeset correctly.

Everything will be handled by the “cm sync” command, no need to run an explicit pull first.

Now the next steps will be resolving the merge conflict at the Plastic SCM side, and then completing the push:

At the end of the day, both repositories will look the same, and will let developers work together at both sides.

Next steps

We’re about to release a “beta program” so we’re looking for enthusiastic developers who would use Plastic SCM to contribute to GitHub projects (or CodePlex projects, or Git projects on BitBucket) and will send us valuable feedback. Of course we’re also open to any other scenario, like enterprise teams using Git as a central repo with members who would prefer to use Plastic.

As you can see, now Plastic SCM can act as a full GitHub client… probably the most powerful one so far for Windows.

The “sync process”, as of today, is just available from the command line (cm sync command) but the rest of the GUI will be fully functional and is what you’d be using on a daily basis prior pushing to Git.

We’ll be launching a registration site soon, but if anyone is willing to try the beta already, please send comments to the post and we’ll get back in touch with you!

Watch the preview here:

Pablo Santos

I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code. You can reach me at @psluaces.