The Times They Are A-Changin': We're Not Your Father's Perforce
Today I’m writing in response to a recent article entitled “Splunk: Why we dumped Perforce for Atlassian’s Bitbucket of Gits”, primarily because it offers a great opportunity to correct a variety of misconceptions regarding Perforce Helix. The TLDR version is that the article contains several factual inaccuracies, and Splunk’s main complaint about Helix is simply no longer valid.
To be fair, Helix has changed a lot in recent years, as has Perforce itself as a company. I apologize in advance for the length of this post, but customers are surely best served by details of our actual product features today rather than vague invective or complaints about limitations shed in years past.
The Industry’s Only True Hybrid
First, it’s false to say that Helix is a purely “centralized and proprietary” version control system (VCS). The truth is that Helix has supported distributed version control (DVCS) for years. In fact, the native DVCS features in Helix are the most advanced in the industry, including things that Git and other systems don’t (and may never) have. Specific examples include support for:
- Narrow cloning to retrieve only a limited subset of files and folders
- Variably shallow cloning to limit revisions cloned by file path, name, type, etc.
- File locking to prevent changes from others to avoid overwriting work
- Repo remapping to specify a different local layout for files/folders as needed
- Consistently speedy performance without limits on file size, number, or type
- Highly granular permissions for security right down to the file level
- Simple integer revision numbers for ease of use and no hash-ID collisions
- Truly safe and simple rewriting of local history before commit
No other DVCS system supports most of those, and given their data models they may never. Many large companies and individuals have spent countless man-hours creating add-ons, extensions, and documenting workflows designed to address problems with large repos in Git, Hg, etc. Sadly, most of the “solutions” involve storing content outside your version control system, which is, rather ironically, at odds with the very reason for using it. Helix simply doesn’t have those problems in the first place.
It’s true that our architecture remains centralized, but then almost nobody uses DVCS systems in isolation. I’ve written about this DVCS myth before: the simple truth is that virtually every DVCS user doing anything of significance needs centralized features as much as ever. Helix is the only true hybrid system that offers the best of both worlds: a centralized architecture to satisfy those needs with the most advanced DVCS features in the industry feeding into it.
Also, pieces of Helix are already open source software (OSS), and I expect more will be over time. In fact, we maintain a site devoted to our OSS offerings, the Perforce Workshop. Anyone is welcome to join up, get our code, contribute, or just sit back and watch what others are doing. In short, we use OSS, and we contribute back to the OSS community, so the OSS spirit is unquestionably alive and well at Perforce.
A Broad Suite of Integrations
Second, to suggest that Perforce Helix lacks integration with “a lot of modern tools” overlooks the large number of integrations offered through a variety of means. For example, we offer plugins and/or integrate directly out of the box with popular development environments (IDEs) like Eclipse, Visual Studio, and even the newest version of KDevelop.
And most standalone editors supply their own integrations anyway. For example, I frequently use Vim and SlickEdit, both of which integrate nicely with Helix. If you’re writing code, the odds are good that your IDE/editor will handle the versioning tasks for you behind the scenes.
Similarly, artists, animators, scripters, and others also enjoy support through a wide variety of plugins for industry-standard applications like Photoshop, Softimage, 3ds Max, Maya, CryEngine, the Unity gaming engine, and most recently, Amazon’s new Lumberyard. If you’re working on designs, animations, images, game scripts, or other such assets, the odds are good that your tools will also handle versioning tasks for you behind the scenes.
Further, users working in Microsoft Office enjoy plugin support, making it possible to store and version documents in Helix without ever leaving their familiar applications. Heck, every single Windows user can handle versioning tasks right in Windows Explorer if desired via a Helix plugin.
And those are just the tools for content contributors. Perforce integrates well with all manner of other tools along the ALM chain such as HP Quality Center, JIRA (and a variety of other tools from Atlassian), Redmine, Bugzilla, Maven, Jenkins, etc. A useful but not exhaustive list of third-party integrations may be found on our web site.
When all else fails, or for the deliberately hard-core, Perforce Helix also exposes its power through a wide variety of APIs. Supported languages include C/C++, the .NET platform, Java, Python, Perl, Ruby, and even PHP. In short, if you need to integrate something with Perforce Helix, you can. We’ve probably got you covered right out of the box, but if not you can always roll your own.
Speed at Scale
Third, to suggest that Perforce Helix is “an impediment to speed at scale” is laughable on its face to anyone who knows our product. Quite the contrary, Perforce Helix is the industry standard for speed at scale. We have customers whose largest commits are bigger than the recommend size for entire repos in other tools. I wrote about this phenomenon after our MERGE 2014 conference as well as after our MERGE 2016 conference. The things our customers do are as astounding as they are ground-breaking.
Let me offer you some numbers I gave at a recent software development conference. Perforce Helix supports tens of thousands of concurrent users, hundreds of millions of transactions a day, billions of files, and petabytes of storage. And to be clear, these aren’t the “hard limits” of Perforce Helix. These are the things our customers are doing in their day-to-day operations. I wish I could tell you what Helix’ hard limits are today, but as far as I know they haven’t yet been hit.
Here’s the simple challenge I would offer: name me the project using Git that works well and performs acceptably at that kind of scale using a competitor’s system. The maximum practical repository size for Git is typically accepted as a gigabyte or two. Do you really want to break up every terabyte of your content into a thousand Git repositories? And worry about storing all their large binary files outside the repository as well in yet another thing to manage via git-annex or Git LFS? I don’t know about you, but I’d rather stick with Helix and not have to do that.
And of course that completely overlooks the challenge of managing (and securing) all that content when scattered around the globe in our increasingly distributed workplace. Unlike other systems, Perforce Helix provides a centralized server architecture that offers you options for synchronizing that content globally for 24/7 operations. Local users enjoy LAN speed connections to local servers, while Helix replicates content behind the scenes over WAN links.
Git Support and Merge-Request Workflow
Now let me focus on the one complaint from the article that previously had actual merit: the need for a thoroughly Git-centric review process. Two years ago when Splunk was looking around, Perforce did not support Git in our code review tools.
But that’s precisely why Perforce added GitSwarm to Helix. GitSwarm is built upon GitLab, so it offers exactly the same type of merge-request workflow that Splunk was seeking and the article touts. While it wasn’t available in time for Splunk’s retooling, we’ve offered GitSwarm now since 2015, so it’s been around for a while, particularly given the speed at which our industry operates. In short, the one objection raised by the article that was legitimate is no longer valid today.
You see, at Perforce we listen to our customers. When they told us they wanted Git-style workflow, we delivered. In fact, we recently convened the first meeting of our new customer advisory board and have added other systems for closer and tighter collaboration/feedback cycles going forward.
Finally, it bears mention that Perforce was acquired in early 2016, so we’ve been going through some recent refocusing and retooling of our own. The new management is absolutely committed to supporting Git and continuing to push the boundaries of DVCS science through Helix’ unparalleled features.
Perforce is also growing and adapting to serve our customers better at every step along the ALM toolchain, a renewed commitment demonstrated recently through our acquisition of Seapine Software. At the risk of sounding clichéd, today’s Perforce is not your father’s Perforce.
If you haven’t recently considered Perforce Helix, you might want to rethink that. It’s free for evaluation and small teams, so why not give it a try today? All you have to waste is all the time and money you’ll otherwise eventually spend confronting the hidden costs of managing Git.