Two version control heavyweights enter the ring, but only one can leave victorious: Git or Perforce. As showdowns go, it might not have the glitz and pomp of Ali versus Foreman, but it’s every bit as serious if you’re a software developer.
There are, of course, many other players in the version control game, with tools such as Microsoft Team Foundation Server, Subversion and Mercurial all having their supporters. Nevertheless, Git and Perforce Helix are two of the most popular VCS tools on the market, and all across the web, there’s plenty of debate about which is the better of these two systems.
Before we look at what people say about these two systems, though, let’s begin with a little background about these competing tools.
Perforce Helix
Let’s kick things off with the older of these two systems. First released in 1995, Perforce Helix was originally called just ‘Perforce’ and was created by Perforce Software – a company formed by Christopher Seiwald. Based in Minneapolis, USA, Perforce was sold to the investment group Summit Partners in February 2016, with Janet Dryer named the new CEO.
Today, it’s still going strong, with versions for a wide range of operating systems, including Windows, MacOS, Linux, Solaris and NetBSD.
Git
Unlike Perforce, Git is a free, open-source solution created by the father of Linux, Linus Torvalds. With Torvalds looking for a distributed version control system that could keep up with his demands, he created and released Git in 2005. Since then, it’s grown massively in popularity. In fact, it’s become by far the most popular VCS in the world.
Now we’ve introduced our two combatants, let’s look at them in more detail and see what people are saying about them.
Note: Clearvision (now part of Eficode) is a Git advocate, of course, so forgive us if we’re a tad biased, but there are lots of reasons why we like it so much, as you’ll see.
Speed
Even when it’s not the deciding factor, the issue of speed is a major contributor most organisations will want to consider when choosing a version control system.
We’ve found that one area where Git comes out on top over centralized VCSs like Perforce is raw speed. You can have the entire project history at hand in seconds; it’s an experience that Aristotle Pagaltzis, a coder writing at www.stackoverflow.com, calls “liberating”.
“Even generating a commit log of the whole project history, one that includes a full diff for each commit, can be done in fractions of a second,” he says, although, of course, in a large project, you will see some slow down. Historically, Git has had issues handling larger files.
In many cases, though, “VCSs that have to roundtrip over the network simply have no chance of competing when it comes to speed, not even over a Gigabit Ethernet link.”
Conflicts
While automation is generally an excellent time-saver, there’s always an element of risk to it, and with Perforce, there have been reported occasions where work has been destroyed by P4Merge’s auto-resolve. While this is generally down to the way the tool is being used, not the tool itself, it does mean that teams using Perforce will need to invest time in training and familiarising themselves with this. Any risk of loss of work is bad; at vital moments, it can turn into a disaster if not managed correctly.
This can be avoided by performing merges by hand in Perforce, much, in the same way, merges are handled in Git. When Git prompts about a conflict, it is actually a conflict, and the rest of the time, Git resolves stuff correctly and saves heaps of time.
Keeping Track of Merges
If you’re used to having one branch that is continuously receiving merges from two other branches, you may well already know what a headache this can sometimes be with Perforce. With Git, the headache is minimised because the result of a merge in Git is actually a new commit, which knows what its ancestors are.
Stashing
Historically, this has been possible in Git but not Perforce. Now, provided your Perforce server is version 2010.1 or newer, you can use the p4 shelve command to the same effect.
Creating Patches
Easy to do in Git, it’s currently impossible in Perforce without using the command line, which can present a challenge to those unfamiliar with the way the command line operates.
Disk Space
“With Perforce, every branch is a copy,” Carl of www.stackoverflow.com says. “That means if your source tree is huge, your disk space gets eaten up fast. This is not even counting the additional space once you start building.”
“With Git, you can have 100 branches and only one branch at a time ever exists. If you specifically want to work on two versions simultaneously, you can clone, do your work and then get rid of one clone if you want, without losing anything.”
Tracking Changes Across Refractors
Carl once again enlightens us here:
“Try splitting BigClass into SmallClass1 and SmallClass2. To Perforce, BigClass has now ceased to exist and two new classes (SmallClass1 and SmallClass2 have joined the source tree). To Perforce, there is no relation between BigClass and SmallClass1 and SmallClass2.”
Git holds a big advantage here because is “smart enough to know that x% of BigClass is now in SmallClass1 and y% of BigClass is in SmallClass2 and that BigClass has ceased to exist … From the point of view of someone who is reviewing changes across multiple branches, [Git’s approach is more useful], because it more accurately reflects the actual change in the code. Git is able to do this because it tracks contained within the file and not the file itself.”
Centralized or Decentralized
One of the key differences between these two systems is that Git is based on a distributed, decentralised model, while Perforce is centralised. Both have their advantages, of course, but with a centralised system, there’s no way to decentralise it later. A distributed VCS, on the other hand, can be centralised.
For some developers, a centralised system is useful. Coder Bart Ruffle, for example, says, ” I regard communication as the most important point – letting others know everything I do. A centralized VCS helps with that.”
However, while there may some truth to this, there are plenty of ways to communicate when using a distributed system, and it’s not necessarily a problem that other coders experience. Indeed, in the comments section of Bart’s blog post, ‘Alexander’ gives a different view:
“Communication. Task trackers were invented for this. But if you want to [let others] know what you are doing — share your local repos.”
The decentralised/centralised preference of a business very often comes down to that organization’s specific requirements, but it’s clear, nonetheless, that Git offers much greater flexibility in the long term.
Related: Download Git 101 – a free guide to the basics
Branch Mappings
If you want to do branching right in Perforce, you need to create a branch mapping. There are reasons for this, which are tied to how Perforce conceptualises a branch. As a developer or a team, it adds an extra step to the workflow you wouldn’t have needed with Git. It’s often a small step, but for some teams, it could make a considerable difference, and it’s something well worth considering when making a choice between the two.
Sharing Work Between Teams
Breaking up a submission is impossible in Perforce. Carl gives us a useful example:
Think about this in terms of Team A, B and C, he tells us. “Team A is working on feature A. Team B on feature B. Team C is working on bug fixes.
“Now, Teams A & B have to fix a bunch of bugs in order to implement their features. The only thing is, they weren’t so disciplined when committing their changes (probably because they’re rushing to a deadline), and so their “bug fixes” are parts of larger submissions that also contain new stuff as far as version control on their branches is concerned.
“However, Team C is now doing a point release and would like to get the bug fixes from the other teams. If they were using Git, Team C could cherry-pick the other teams’ relevant changes, split them up and only take what they needed without worrying about introducing any partially implemented features. With Perforce, Team C can get the affected files but would have to separate the relevant changes using a much more manual process.”
Changing to Amazing Source Control Engine X
“If you decide to change what you use for source control [to system X],” Carl continues, “extracting your source control history from Perforce and moving it to new system X is going to be a nightmare because it is closed source and the best you can do is guess …. At least with Git, it’s open source, so it eliminates a lot of the guesswork involved.”
So… The Winner?
Of course, a lot of the time, the decision between Git and Perforce is made on a case-by-case basis by each business. While we prefer Git, a lot of teams prefer Perforce, particularly those in the gaming industry.
As previously mentioned, we’re Git Git advocates. For us, even with a close comparison, Git comes out on top, but to counteract any potential bias, here’s a quick list of the pros of Perforce, as proffered by Emil Sit, a software developer writing at Quora:
“Perforce:
- is often considered a more sensible choice for large repos.
- has a write-through proxy.
- tracks integration on a per-file basis, not per commit, which some teams find an advantage.
- has good Windows support (notably clients, but also line-endings).
- has very flexible (and partial) checkouts (with customizable workspaces/clients), whereas Git makes this more complicated.
- can output most command results automatically in pickled Python (with the -G flag) or in shell-parseable format (with “-z tag”).
- has integrated mechanisms for access control to parts of the namespace (“p4 protect”), whereas Git leaves that to the hosting environment.
- may well be an easier sell in a corporate environment.”
And, of course, you can choose to use Perforce with Git (there’s an app for that!).
Both have benefits. Many love Git for its simplicity and speed, while Perforce works as a charm for game devs and big corporations like Microsoft.
Which is your favourite? Let us know in the comments.
Sources
http://www.perforce.com/blog/140219/git-p4-no-choice-required
http://stackoverflow.com/questions/222782/git-vs-perforce-two-vcs-will-enter-one-will-leave
http://programmers.stackexchange.com/questions/85845/why-big-companies-use-perforce
http://blogs.atlassian.com/2013/11/dont-move-to-git/
http://www.quora.com/What-are-some-advantages-of-Perforce-over-git
If you’d like more information or help configuring any of your Git tools to your specific development environment, Clearvision can help. An Atlassian Platinum Solution Partner, our consultants are experts in Atlassian, Git, and all things agile get in touch with your requirements today!
Published: Apr 12, 2018
Updated: Jun 22, 2023
