Plastic SCM vs Git - 2018 edition
(This blogpost was originally published at Medium.)
I don't know about you but I've always enjoyed a good David and Goliath story. There's something about the heroic underdog standing their ground against the big foe that captures my imagination: whether it's Frodo going up against Sauron, Luke Skywalker taking on the Empire, or Plastic SCM holding its own against Git.
Ok, maybe the last isn't quite the same - but hear me out. At conferences or other events, people always ask me, "How is Plastic different to Git?" They are always curious (and at times mildly affronted) as to how we can possibly compete against the much-loved Torvalds' dominant creation that's used and contributed to by multinational giants like Atlassian, Microsoft, GitHub, GitLab, and others.
With powerful friends like that, it may seem entirely crazy to put your trust in Plastic. And yet, over 2500 developer companies including large-and-small game studios, insurance agencies, health care companies, aerospace companies, automotive companies, and more have done exactly that.
So, what is it that makes us different? In short, we've taken the age-old underdog story and tweaked it. While Luke Skywalker exploits the Death Star's single weakness to entirely destroy it, at Plastic total destruction isn't what we're after. At least not entirely.
Real branches
Take branches, for example. For us, simplification is strength. While Git branches are just pointers to a given commit, the Plastic version are changeset containers (commits in Git jargon). This means that Plastic branches match exactly what you have in your head.
Whereas in Git you have to continually think in pointers, a Plastic changeset belongs to a single branch. This avoids the difficulty of having to figure out where a commit was created.
In this way, you can see the heritage and immediately understand, per task, where lines have been touched without having to rely on commit messages. Our branches are all about mapping one-to-many branches in a changeset. Like I said, simple:
This level of clarity makes a big difference. It's common in the world of Git to delete branches willy-nilly, as they blur the entire picture, or because most GUIs crash immediately if you try to open a repo with more than 2k branches (although the CLI can cope with that).
If you stick to the Plastic-style branch-per-task, you'll rarely need to delete as you can have repos with 10k, 20k, or even more for the brave among you. What's more, as it's all your history, there's no problem at all. With Plastic, you'll always know where a changeset was created - something that's almost impossible to tell with Git.
The difference here has everything to do with full traceability and ease of use, which is something that matters to all programmers. Every single Git instructor I have ever spoken to has told me that they have to figure out how to make students think in terms of pointers and not branches as they used to.
It's much more intuitive in Plastic - when you expect branches, there are branches.
Work centralized
So, we've covered how our simple, easily traceable approach to branches helps us stand out, but how else are we taming Goliath and turning Git's weaknesses into our strengths?
One word: flexibility.
Just like in Git, you can have your local repos in Plastic and work distributed. However, you can also work Subversion-style. This means you have a local working copy, and direct checkin to the server, without intermediate push/pull. As Git's design means you need a local repo, this is entirely impossible with them.
Now, you might not like having a local repo - it seems to be one of those love it or hate it things. But having this flexibility is often very important for game designers, animators, 3D artists etc., or other creative-types in gaming studios. They generally prefer to work centralized, expecting the version control to stay out of their way and do its job.
When it comes down to it, it's the difference between "checkin and done" versus "checkin and then push." It's just easier.
Interestingly, we also find that many coders who use extremely fast networks prefer to work centralized. Although we say "Subversion-style," Plastic is not like SVN. Our branches and merges are actually so strong that they even outperform Git. This means that working centralized doesn't take away from any branching powers. The reality is that for many Git is all about branching or merging, and working distributed is done at a cost to you.
Work fully distributed, centralized or even multi-site - like I said, Plastic is about flexibility.
Even with huge repos, Plastic takes the strain
We have customers with a staggering 5TB+ repos. I know what you're thinking - that if they're that big, there are too many unnecessary files. Not long ago, I was talking to some GitHub and GitLab developers who said exactly this. However, if you're working on a game project, automotive design, or anything else of that size, there are inevitably going to be large graphics, documents, and video files. Of course, you could ask your customer to put their code in Git and binaries in Dropbox (give that one a go...), but surely they want a system that solves problems - not creates more!
With Plastic, you checkin big files and you're done. It doesn't break. It doesn't slow down. It doesn't involve unpopular workarounds like Large File Storage. Plastic's ability to handle everything you throw at it allows us to work with lots of different games studios. Whether large ones with 300+ artists like Telltale, or small indie ones with large projects, this durability when it comes to repos is key.
And this same size-friendly approach applies to our Cloud solution. At GitHub, they ask you to remove your repo as soon as it grows over 2GB. The average repo in Plastic Cloud is 50GB+. That says it all, I think.
Version directories and moves
Here we have another difference that goes back to the underlying design. Rename a directory in Git containing 1000 files, and you'll enjoy the headache of 1000 individual file moves. Do the same in Plastic and... you get a directory renamed. Isn't that the solution you would expect from your version control?
Although these versioning directories complicate our implementation, it allows us to precisely track moves and renames. In the end, we promise it will repeatedly save your life during complex diffs and merges.
Visualization and GUIs included
When you've been working on visualization and GUIs for as long as I have, you tend to forget just how important they are. Honestly, I couldn't imagine life without them.
When you install Plastic, you get a complete and extremely visual graphical user interface. Just check out our gallery if you don't believe me. As for visualization, one of the key features is our Branch Explorer, which turns repo visualization into something natural and easy to manage.
At the end of the day, taking care of the full stack is labor intensive. We don't just work on the server and on the command line, we also develop the GUIs and third-party integrations. This attention to detail means consistency, performing above and beyond Git tools that tend to just be command line wrappers.
In Plastic, we also include merge tools, with the pretty unique code move detection. With this, you don't have to rely on unified diff or install Kdiff3. It also includes side-by-side diff, which is still rarely included by Git GUIs even 12 years after Git was first released. And, if all that wasn't enough, you can find the cherry on the Plastic cake with unique features like "semantic version control."
Plastic speaks the Git language
Now, even with all our incredible features, we understand that some of you or your collaborators have decided to go with Git. Don't worry, we don't mind. In fact, we made it easier for you all.
Every Plastic client can push/pull to a Git server and every Plastic server can act as a Git server and handle push/pull from Git clients. This Git interoperability affords great flexibility for teams moving to Plastic from Git, or if ever you need to interact with other teams using Git.
Wrapping up
Our David and Goliath story is ongoing. We enjoy testing the armour of our domineering rival, and using their weak points to our advantage. I'm sure I'll still get plenty of questions in the future about how we compare, but for now I hope I've provided a comprehensive answer. Lastly, for those of you who like everything in bite-sized form, in summary, at Plastic SCM we provide:
- Branches that are simple to understand
- Merges that are even more powerful
- Big repos, with big files to match
- Visualization
May the force of the Plastic underdog be with you.
(Revised by VeraContent.)
0 comentarios: