Why big companies use Perforce? [closed]

Question

I heard about some big companies e.g. Google, Facebook use Perforce

Are there any reason why SVN/Git cannot replace Perforce?

Answer 1

The justification is perhaps less relevant than it once was, but Perforce tends to perform better on large repositories than Subversion. This is one of the reasons Microsoft acquired a source license to Perforce to build Source Depot; NT's repository is a monster, and not many products, commercial or otherwise, could handle it.

Also, at least at one time, the visual tools for Perforce were way, way better than what's available out of the box (so to speak) with Subversion or Git. If you're using Meld perhaps those things matter less than they once did, but there are still a few things that Perforce did very nicely, including visualizations of branching and merging which, although I don't have a detailed memory of since it's been about 3 years since I last touched Perforce, seemed more sophisticated than, for example, Github's approach to that.

Once you've used Perforce, you may understand what its advantages are in practice. They've long offered a free two-user server option, and depending on which source code management systems you have experience with, you may find it worth the cost of upgrading after your team tests it out for a while. For smaller shops, this, plus network effects of developers who have used it and liked it, are why Perforce ends up getting paying users. There's probably not a whole lot of wining and dining of CTOs to sell Perforce at companies with small development teams, in contrast to Dmitri's cynical remarks, but it is used in such places.

Most of the projects I've worked on outside of Microsoft can be reasonably well-served by Git, Mercurial, or Subversion, and I'd say the majority of companies I've worked for use one of those options. But there is a sweet spot, usually a combination of repository size, branching and merging model, and team experience/history that leads people to use commercial tools. I've rarely seen large Git repositories, for example. This may not be due to any intrinsic limitations of Git; I admit full ignorance of that. But in some projects (like Windows NT) there may be some practical limits to free solutions.

Answer 2

I'm reasonably proficient with svn, git, and Perforce, both as a user and at setting up and maintaining servers.

For a company, or even a lone programmer like me, source control is a cost incurred in support of the real money-making activity, which is developing and selling code. So there are several factors to consider:

• How well does it fit with your development model?
• How easy is it for developers to learn and use?
• Are routine operations for developers fast?
• Is the process of using it a distraction from their real job, which is to write code?
• How easy is it to set up and maintain?
• How much does it cost to purchase and maintain?
• If you need help, how easy is it to get it?

I'm going to skip the tl:dr detail about the pros and cons of the individual systems. Suffice it to say that when I went back to full-time consulting last year, I reviewed all three to decide which would let me make the most money as fast as possible by delivering quality software to my clients, and without requiring a lot of unpaid fooling around. When I took the political consideration of "FOSS is good and non-FOSS is evil" out of the equation, I wound up forking over for a Perforce license.

And that's why big companies pick Perforce, too.

---

Here are the tl:dr details from the comments, plus a little more.

Addressing svn is easy: compared to Perforce, it's dog-slow. I worked at a company that did embedded Linux for cell phones, and our complete sources ran 9 GB; they used Perforce. Once you had the code, updating the latest sources normally took seconds on the LAN, or a couple of minutes over a VPN connection from my house. With svn, it would have been minutes and hours respectively.

git vs. Perforce is more complicated. Many companies feel they have good business reasons to use a centralized repository with access control, and to make it easy to commit there and hard to do anything else - and Perforce fits that model perfectly. However, git positively encourages people to work in a local branch, and there's no way to get it to work any differently. A developer can work entirely in a local branch and never commit to the central repo - so if a company doesn't want its people working that way, Perforce is a better option.

There are other problems with git for some business needs. I worked at a company that used git, and I don't know how many times I heard this discussion: "I wish we were using [some other VCS], because I need to do [this] and I can't with git." "Of course you can do that with git." "How?" "Well, first you need to write a bash script..." "Never mind."

And then there's the time it takes to initialy populate a source tree that has a lot of history. With Perforce, because the history is kept on the server, you just get the latest versions of all the files, so it's really fast - even setting up that entire 9 GB tree I mentioned only took a couple of hours over a VPN. With git, it can take somewhere between a long time and an eternity. I sometimes have to clone GTK+ or the X server git repos, and that's a long lunch break, or maybe time for bed.

Really, it's a matter of the right tool for the job. svn works fine for most of Apple's open source efforts, and would be awful for kernel hacking. git works great for GTK+, but is incredibly slow for working inside WebKit - the source tree and history are just too huge (as I found out the hard way working with code from WebKit's svn-to-git portal). Perforce works well if you have a giant source tree and need centralized control. Each of them works fine in the right context.

Answer 3

GIT especially, and SVN to some extent are not that old -- if you needed solid version control in the mid 90s, you almost had to go commercial as SVN was in its infancy and CVS was, well, CVS. Once you've got alot invested in a system, moving it can be a bear.

Oh, and the guys who do make these decisions probably never interact with the version control system but do get wined and dined by aforementioned sales staff.

Answer 4

I've been a programmer in the games industry for almost 9 years now, and every project I've ever worked on has used Perforce. I suspect that there are a few things keeping Perforce in use in that particular industry.

• People have been using Perforce for a long time, and are pretty comfortable with it, making them hesitant to switch to another solution. Decision makers may also be hesitant to put their 30 million dollar project in the hands of software they've never used before.
• Many companies/teams have added Perforce support to their in-house tools, which might require a significant amount of work to update to support another VCS.
• While programmers might have an easy time switching to another Git/Hg/SVN, there are a lot of less technical members of a game development team, such as artists, designers, and producers. Getting them comfortable with the new system might take a lot of time, and I'd be willing to bet they'd be quite resistant to the change.

Answer 5

Maybe, maybe they like Perforce because Perforce is better?

• Perforce is fast. Much faster than Subversion or Git.
• Perforce merging is better than Subversion or Git. Git doesn't really do merges and Subversion's version tracking isn't so good, at least in 1.5.
• Perforce has excellent customer support.
• Perforce combines Subversion's repository revisioning with individual file revisions. Perforce allows you to view repository revisions via change lists or individual file revisions.
• Perforce does a much better job with multiple change lists than Subversion. Subversion's changelists are somewhat of an afterthought and I know few who use it. Perforce is built in. If you move a changed file from the default change list, it doesn't get accidentally committed.
• Perforce allows you to specify your working directory layout. For example, if you have a standard source code directory tree, but some customers have custom source, you can overlay the custom source over the standard tree. You can easily do sparse checkouts by specifying only those items you want to checkout.

Okay, before you think I'm a Perforce Fanboi, the last time I recommended Perforce to a company was over seven years ago. Perforce costs $800 per license -- which is cheap compared to ClearCase, but way expensive when compared to Subversion. I have a hard time justifying Perforce over Subversion.

Plus, most developers are use to Subversion. They don't want to learn Perforce which has a different way of working than Subversion. In Perforce, you have to create a client and you have to mark files for editing before you can modify them. You don't have to do that with Subversion.

There are fewer integrations with Perforce over Subversion too. Part of that is due to the use of the client. It just doesn't play well with VisualStudio or even Hudson. Part of it is due to the fact that Perforce has to create the client integrations.

There's a cost to proprietary license call the administrative cost. Imagine if you could license a piece of software for a $1.00 per user. Heck, let's make it two bits. A thousands licenses would cost you only $250.

Now, you need a full time person managing the license. An average technical worker stays around at a company for about 2 years. That means 500 people each year will be leaving and another 500 come. Ten people each and every week have to have the license changed. Then, there are times when the project picks up and you need another 250 licenses. Those must be ordered, entered, and maintained. That can take weeks.

That's why many commercial firms have moved to open source. It's not the cost of a license. You pay a developer $150,000 per year, what's another $800 for a Perforce license? It's managing that license. Perforce looks great when compared to ClearCase: Faster, easier, cheaper, better. But, against Subversion? Perforce might be faster and maybe better, but is it $800 better? Is it managing the license better? Is it not using a desired tool better?

That's why Perforce may be having problems.

Git isn't the end-all be-all tool. It works great in circumstances where you don't want centralized control of who has access to a repository. But, it can be a pain in many circumstances. The way I put it is this way:

1. You run an open source project. Would you be happy or upset if a million people had a copy of your entire repository?
2. You are running a financial trading desk that uses proprietary software to get an edge on your competitors. Would you be happy or upset if a million people had a copy of your entire repository?

If you are doing centralized builds, you need everyone to use a single repository anyway. What is the advantage of a distributed system in this circumstance? In fact, it can encourage people to work off line. The developers may simply go off on their own merry way and not commit anything until the last minute. Then, you spend two frantic days trying to get everything working again.

I'm not against Git. I've recommended Git in many cases. These include distributed teams with poor connections to each other, or places where you don't want to track everyone who has access to the source repository.

For example, a college computer science department wanted to get their students to use source control and put their code there for the teachers to look at. Great idea. Too many kids leave college without understanding standard build and development procedures. I recommended Git.

By using Git, the administrator of the repository only has to take commits from their fellow professors. They don't have to worry about individual students. The professors can allow the students to commit to their version of the repository. Students can work in groups, and each group can share their version of the repository.

If the college used Subversion, someone would have to know all of the students and give them all access to the central repository. They'd have to manage who can check in what and where. If a professor assigned a group project, that would have to be setup and managed. You'd need a full time person just to manage that.

This isn't a football game where one team is better than another. Tools work in different ways and each have their advantages and disadvantages. Perforce is a great tool. Unfortunately, circumstances have developed that make it hard to recommend.

Git is great, but I keep falling back to Subversion for my personal source repository. After all, I don't share it, and Subversion is just easier to use. I use Git for personal work if I have a small team because I don't have to keep my repository up full time on the Internet. For most commercial sites, I still find that Subversion works the best. But, there are circumstances when Git shines.

Answer 6

I don't know if the 'wine and dine' bribery is still applicable, but for most managers when they decide to find a product they will read up in various publications (targetted towards management) and look at the brochures and pamphlets extolling the product's virtues.

Guess what, FOSS products don't feature in those places!

So, its almost a given that most management-purchasing decisions are driven by advertising and marketing. They may perform evaluations, but of several of such products.

The other reason is due to maturity. Some products we use today are only recently stable enough for serious business use, some have no support options, some have no proven track record as business solutions. These are important things to consider (though as a techie I will happily evaluate FOSS solutions if the risk of using them and having them fail is minimal to keeping the business running) and some managers are rightly wary of not having them around. They are accountable to their bosses and will feel much more comfortable if there's a support organisation behind the product - you have one for your business after all.

Lastly, while many FOSS products do have support behind them (think Collabnet or Wandisco for SVN), it still gets the 'made by geeks in their back bedroom' reputation. We all know that's generally b****t and the best FOSS competes incredibly well with commercial offerings, but my manager still needs to be convinced. maybe he just doesn't realise the difference between the immature and the mature FOSS products; maybe he doesn't care.

Anyway, Perforce is a fine SCM, there's no reason not to choose it. I could say the same for other SCMs, but there again, I can say only bad things about some others, and still have nightmares when it comes to a certain couple of products.

Answer 7

Because tools like Perforce have salesmen to wine and dine people in charge of purchasing, while Git doesn't. Of course, that's just the cynical side of me talking, but it is a cynicism brought on by seeing the process up close.

Just to make it perfectly clear: I don't mean that every time you see your CIO stumbling drunkenly down the corridor, expect to be using a new versioning system next quarter. Just that there is a disconnect in many organizations between use and acquisition. Of course there are other reasons that companies use Perforce: for instance, they may have already invested heavily in its implementation in their workflow. But generally---and this question is very general---there is no functional advantage to not using FOSS tools.

Answer 8

Probably the same reason my company refuses to use a lot of open source software (not that I agree):

When something goes wrong, they want someone they can call and yell at.

Answer 9

While all answers talk about big companies using P4 ( and they answer why Google did use P4 ), one of the main reasons Google continues to use Perforce is that Perforce allows you to checkout a subtree of the repo whereas you cannot do that with Git. With large source repos like Google's that made a huge difference.

And as far as I have heard, Facebook use SVN and Git-SVN

Answer 10

Because SVN is, well, SVN, and Perforce (from the one time 4 years back when comparing tools) does some things better than SVN. (Branching is one among them I think.)

And GIT is a Dvcs, as in distributed. For company teams, the distributed part might well be something the neither care nor wish for.

Answer 11

Another reason that big companies tend to buy big, klunky, "enterprise" version control systems:

Mid- to upper-management in IT departments see VCS as something that every single project uses, or you can enforce it's use. Once you've enforced the use of a VCS, then why not put a little "process" in there, as well? I mean, you've got the opportunity to specify an "enterprise-wide" system, why not get it under central control, and add "disaster recovery" and some "workflow features" so you can say "We're CMM Level StraightJacket compliant!". A VCS is just too easy of a target to put workflow enforcing features, is what it comes down to.

As far as choice of some ickky-poo, cruddy software (Serena Dimensions), it's said that a few rounds of Bikini Golf in the Bahamas with a few 20-something female sales staffers can convince a Director or VP of just about anything.

Answer 12

Large companies need a centralized model of some kind. Once the developers are done developing, it gets handed off to customer support. Do you really want to be in supports shoes when they have to comb through 50-200 distributed developer repos? And builds are done based on the central repo, builds must always, always, always be traceable, and reproducible. You learn this the first time you get taken to court over some silly patent infringement.

Git doesn't work as well in this model. If you have a smaller company, or one with poor VPN access, that's where it really shines.

Answer 13

One reason most big companies use Perforce may be that there are more professionals in the IT department who have a lot of knowledge about it and have years of experience trouble shooting issues related to it.

I feel that in the future companies may start moving away from Perforce and more towards GIT ...most developers I know seem to prefer it!! Also check out http://whygitisbetterthanx.com/#git-is-fast for further evidence on why Perforce may not be as dominant in the coming years!!

Answer 14

Some times ago, we switched from a set of VCS (I know for sure that RCS, CVS, ClearCase, Perforce were used previously, there could be others as well) to Perforce as unique system in use. That wasn't a small project: the migration took over one year. The team (I wasn't part of it) in charge evaluated several VCS, and at least git and svn were considered as well as those already in use. As I remember their report, they filtered out the tools without the needed features and then considered:

• performance on typical usage, especially for remote sites

• resource requirements

• importance of the changes needed in the working habit

• support availability and cost

and Perforce was quite a clear winner overall. git was slightly better for the first point, but at disadvantage for the others.

Answer 15

Once upon a time, not so long ago (when the IDE was called VI), the only free (open source) systems were CVS, RCS and SCCS.

• None of these could even cope well with a file being renamed.
• They did not record merges, so if two branches were actively being worked it was very hard to merge until the work finished on one branch.
• They did not scale well to very large code bases
• They did not provide the level of access control and process informant that large projects wanted.

There was lots of commercial source code control systems out there, most of these were provided by a single machine vendor (IBM, DEC, HP, etc) and only run on their hardware.

Then a few companies stated to sell cross-platform commercial source code control including Perforce and ClearCase.

ClearCase was built on RPC that did not work well over wide area networks (yet alone the internet) due to lots of small network packets being “round tripped”, also IBM and rational saw ClearCase as a “cash cow” and never showed it much love.

So the only “old” commercial source code control systems that is still in common use is Perforce. Once perforce is in use and integrated into build systems and bug tracking systems there is very little short term benefit for a company to move to anything else.

So to sum up, perforce got the “foot in the door” when there was not many other options, and they have not mess up enough yet to get people to move away from it.