Thoughts on version control, software development, branching and merging from the Plastic dev team

Direct push/pull from Plastic SCM to Git

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!

1. We're handling direct connection to the server, no direct connection to file://. The goal is to use plastic as "github client", not to clone another git local repo... In fact, locally accessing the git repo would have been much easier to do :)

2. Sure, we do support http too.

3. No ssh support yet I'm afraid

4. and 5. Yes, of course, if there are features that one of the two don't handle, then it could be a potential problem. In the case of the evil twins: git doesn't really mind, we do, so it will depend whether you run the merge on git or plastic side.

Well, I've mentioned my dislike Plastic's handling of identical evil twins in general (seems to happen in our environment fairly frequently, but I also blame VSS for that).

I wouldn't mind trying the alpha, but it will be 2-3 weeks before I can really get down into it (we have a December release). I also want to give feedback on the command-line side of things since that is how I usually work.

Oh, another question. We are having trouble importing VSS into Plastic, so we tried doing a VSS to Git to Plastic conversion but that also choked. With this, could we do a VSS to Git conversion, and then sync a (very) large Git tree into Plastic?

I'm very impressed by this feature! Maybe I can bring some friends of mine to the "non-shell side of the force"!Some friends are using git in their work and they were kind of reluctant doing using the old sync ways! :)

Just keeping the old doubt of D. Moonfire about evil twins, if all the merges and folder tracking were done in Plastic, it will not have any problem pushing the changes back to git, right? :)

> I'm very impressed by> this feature!> Maybe I can bring some> friends of mine to the> "non-shell side of the> force"!> Some friends are using> git in their work and> they were kind of> reluctant doing using> the old sync ways! :)

It would be great if you can ask your folks to give it a try! :)

> Just keeping the old doubt> of D. Moonfire about evil> twins, if all the merges and> folder tracking were done in> Plastic, it will not have any> problem pushing the changes> back to git, right? :)

Well, once the conflict is solved, you just have to push to git, so whatever you solve in plastic will be marked there