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

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

  • 34
    I heard Google uses timestamp-named folders on a shared drive! ;) Commented Jun 21, 2011 at 14:50
  • 10
    Only the shared drive uses MapReduce, so they are cool Commented Jun 21, 2011 at 15:28
  • 4
    A big issue will be support. When you buy Perforce you are buying support from the developer of the system, something you might not get from Git.
    – ChrisF
    Commented Jun 21, 2011 at 16:30
  • 12
    @Anto: Who cares what Linus says? Just because you're a brilliant kernel developer does not mean you know best about everything everwhere. Commented Jun 21, 2011 at 19:33
  • 5
    Having just come from the Perforce User Conference 2 weeks ago, I can tell you Google uses perforce. They get over 10,000 submits a day to their 1 server.
    – aflat
    Commented Jun 22, 2011 at 1:26

15 Answers 15


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.

  • 3
    Thanks for providing a reasonable answer besides the cynical "wine and dine" theory. It may be true for a lot of companies, but there are some legit reasons that companies go with Perforce (or rewrite it :P ). I can't imagine trying to handle the NT source in SVN. It's true that SVN and Git are catching up, and maybe for a new large project, one of them is the right decision. But think of the costs associated with moving a live project as big as Windows (all versions) from one source control system to another. It's not worth the cost, especially when the current source control system works. Commented Jun 21, 2011 at 18:33
  • 1
    Actually, they did move from SLM (an internal tool) to Source Depot (a fork of Perforce), so it was probably worth the cost to somebody in that case. But yes, it's not worth the cost unless there's a pretty substantial benefit.
    – JasonTrue
    Commented Jun 21, 2011 at 18:46
  • 1
    discuss.fogcreek.com/joelonsoftware/… has some of this history from mostly outsider sources. (I've been an outsider since 2004, FWIW).
    – JasonTrue
    Commented Jun 21, 2011 at 20:54
  • 3
    I'm not sure of the large repo situation. I manage one, it is 12Gb repo (ie the compressed server directory is 12Gb) and has 320,000 revisions in it. Its plenty fast enough. Chances are Microsoft used Perforce because SVN didn't exist back in 1999. maillist.perforce.com/pipermail/perforce-user/2001-August/… and subversion.apache.org/docs/release-notes/release-history.html
    – gbjbaanb
    Commented Jun 21, 2011 at 21:23
  • 8
    @gbjbaanb, that's not a large repository...these days it counts as a medium-sized one. ;) See e.g. research.google.com/pubs/archive/34459.pdf Commented Jun 23, 2011 at 14:14

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.

  • 2
    Is the problem that large companies put their code into one repository? What about putting each 'module' or 'application' into a separate Git repository, so that these repositories' sizes are manageable? Each of these repositories would then import required functionalities using Git's submodule feature. In this way, the maintainers of the repositories would occasionally pull their submodules to obtain updates or new features, and only then would users of that repository require updates larger than the code of the repository itself.
    – Carl G
    Commented Feb 12, 2013 at 7:29
  • @Carl G: If you read all the answers here, you'll find a lot of reasons people have chosen Perforce over git that have nothing to do with git's capabilities around repositories or submodules.
    – Bob Murphy
    Commented Feb 12, 2013 at 23:57
  • I was trying to address "the time it takes to initialy populate a source tree that", but actually I can see that the submodule issue I mentioned is irrelevant because the submodules contain all the histories of those repositories too. I guess the only way to cut down on history would be to use binaries of the dependencies.
    – Carl G
    Commented Feb 13, 2013 at 4:58
  • Well, with git you can do a shallow clone, and get only a small amount of history, or perhaps only the latest files (git clone --depth 1). This works for git sub-modules too. Commented Dec 16, 2016 at 5:13

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.

  • 4
    +1. We switched to git relatively recently, and had to run perforce for rather long time — just because everything else was inferior.
    – 9000
    Commented Jun 21, 2011 at 16:38
  • 11
    Although IMO Perforce wastes a lot of my time. We still use it at work because we have invested time in developing custom tools that interact with it. To switch we would have to rebuild those tools.
    – m4tt1mus
    Commented Jun 21, 2011 at 18:44
  • 2
    Perforce and ignorant developers made me hate checking in code. I would rather write code with crayon and compile that. Commented Jun 21, 2011 at 23:08
  • I think you should take a look at perforce before commenting.
    – Toby Allen
    Commented Mar 7, 2015 at 20:55

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.
  • 19
    I think "old" developers (+10 years) are probably as resistant to change as "non-technical" people. Commented Jun 21, 2011 at 17:46
  • 3
    +1 on this, specifically for this industry. Video game programmers tend to have so much on their plate, that changing the infrastructure they work with is a scary proposition. "If it ain't broke..." is a bit of a mantra, and often prevents the industry from moving on from older solutions, even if they may be more suitable. Commented Jun 22, 2011 at 16:06
  • 2
    @Wayne -- totally ageist comment. I am over sixty and am the lead proponent for change and innovation at my middling to large site. James Gosling was 46 when he started writing the first JVM. Ken Thomson was 49 when he came up with the UTF-8 coding scheme and 63 when he started working on the GO language. Commented Feb 8, 2015 at 2:39
  • 1
    @JamesAnderson I think you're probably spot on there. And if your organization doesn't have a culture of improvement then you'll see the Dead Sea effect come into play. I wonder if it's possible to change the system as a whole, or if we can only fiddle with our little part of it. Commented Feb 9, 2015 at 16:06
  • 2
    @MikeO'Connor You also forgot to put that games use a lot of binary assets. Being able to exclusively lock binary assets is a HUGE plus. Commented Dec 3, 2016 at 6:14

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.

  • 42
    Wait what? You lost me here "Perforce merging is better than Subversion or Git. Git really doesn't really do merges [...]". Can you explain that one? Commented Jun 21, 2011 at 21:02
  • 2
    Actually I find Git pretty good for merges, more pleasant than old-school scm tools, but when in svn I miss being able to put things into a "don't check in" changelist like I often did with Perforce. (I've tried doing it in SVN, but still end up accidentally checking things in because svn and p4 changelists behave differently).
    – JasonTrue
    Commented Jun 21, 2011 at 21:23
  • 13
    @SverreRabbelier 3 years later, and there are still people waiting for an answer to your question.
    – Navin
    Commented Feb 28, 2014 at 20:27
  • 1
    "because Perforce is better" ... "This isn't a football game where one team is better than another". ...
    – RJFalconer
    Commented Apr 1, 2014 at 14:40
  • 5
    perforce is fast. much faster than svn or git. --- benchmarks, or it did not happen... ;p
    – sjas
    Commented Dec 27, 2014 at 18:04

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.

  • This was a more compelling argument a decade ago but lots of FOSS products are very much mainstream today; including SVN, which is used at some big companies.
    – Jeremy
    Commented Jun 21, 2011 at 16:00
  • I don't care that FOSS has the right things to compete - I care that my manager thinks they don't. Besides, some big businesses do move slowly so they're still getting there, it will take a few of them another couple of years to consider evaluating FOSS products.
    – gbjbaanb
    Commented Jun 21, 2011 at 16:08
  • gbjbaanb You misunderstand me. I do not think the factors you are describing are nearly as relevant at any level of management as they were a decade ago. While that might be your situation, it would be erroneous to generalize it. FOSS is mainstream, meaning it is adopted by most large companies and used in core systems.
    – Jeremy
    Commented Jun 21, 2011 at 16:54
  • 6
    I think this is a key point: FOSS tools don't advertise themselves, really because they have no reason to. Part of this is the brochures and stuff you mention, but even if I Google "comparison SCM systems" or "comparison version control system" the only things I find are those done by Perforce. Sure, I have to consider the source, but I don't know of FOSS tools taking the effort to advertise themselves and talk about why they are the best. I know we look down on commercialism, but sometimes marketing and advertising actually helps me make an informed choice.
    – Chance
    Commented Jun 21, 2011 at 17:26
  • 1
    I think there are two excellent reasons not to choose Perforce: 1. Branching is very expensive, and 2. The checkout-then-edit process makes offline work very difficult to reconcile. Commented Jun 21, 2011 at 19:40

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.

  • 13
    It may sound cynical, but essentially you have hit the nail on the head. In my own company I struggle to promote any FOSS solution, as the exec have a perception that if it's free it can't be any good.
    – wolfgangsz
    Commented Jun 21, 2011 at 15:02
  • 1
    amen to that, though I might have converted them a little when they replaced our SVN solution with an 'enterprise' one that cost a flipping fortune, required consultants, 2 contractors to admin it, and after much wailing, gnashing of teeth, buggy operation and the death of our productivity ... was thrown out and replaced with our old SVN solution.
    – gbjbaanb
    Commented Jun 21, 2011 at 15:34
  • 7
    Google isn't really known for this sort of culture.
    – Jeremy
    Commented Jun 21, 2011 at 16:02
  • 11
    @Chance: What sort of things do you contact tech support for? I've used CVS, Subversion, and Mercurial, and i've never once found myself wishing there was someone i could call. If i have a problem, i google, or i post a question, and it's solved, usually in a few minutes. I'd suggest that a source control tool which requires support from the developer of the system has a serious problem. Commented Jun 21, 2011 at 17:47
  • 2
    @TobyAllen : not for about six years (note the date of the question) But these days it looks like even Perforce wants to use something other than Perforce: perforce.com/git
    – Dmitri
    Commented Mar 8, 2015 at 18:42

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.

  • 2
    I agree: this is a big reason for a lot of IT departments, but it seems immature. "It's not our fault, it's THEIR FAULT". Picking an inferior product just because of the "one neck to wring" finger pointing potential seems like an infantile decision. Not that it isn't often made, just that it seems babyish. Commented Jun 21, 2011 at 17:37
  • Your answer doesn't refer to Perforce's tech support. Too bad, because if you knew how good it was, your answer might not have come up. Perforce tech support is stellar and committed, and they get things fixed FAST.
    – Br.Bill
    Commented Nov 28, 2017 at 22:29

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

  • 1
    Absolutely, subrepos encourage and ease code re-use. This is why I choose Perforce when I have a say in the matter. Big deal! Easily mix and match code from different repos (hg's subrepos), tracking who is using a particular subrepo, ability to easily track checkins, branches and merges to all repos. All the while making it super simple for the end developer with a single line client spec and keep the details in the branch spec for the super users. Right now, I am forced to use Mercurial on a large project and dealing with sup-repos with hg is costing a LOT of money in lost productivity.
    – stephenmm
    Commented Mar 20, 2012 at 19:31

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.

  • 5
    You can use Git just fine with different workflows, so being distributed is not an issue... unless the company team is clueless. whygitisbetterthanx.com/#any-workflow Commented Jun 21, 2011 at 16:34
  • 2
    I would not say that Perforce does branching well... creating Perforce branches results in a busy copy of everything branched. SVN branches by lazy copy, so it branches a lot faster. Commented Jun 21, 2011 at 19:41
  • 1
    @Jason - branching on subversion happens faster than I can type: "svn cp ... ; svn switch ... " On perforce branch creation is insanely complex; create a branch spec, create a workspace, integrate, commit. Heck, with perforce it's all like that. Without fast and easy branching, I consider an RCS to be essentially unusable. Judging by net traffic and the speed of enhancement, it looks like Perforce is an end-of-life product. Commented Jun 23, 2011 at 21:32
  • 1
    @kevin, I'm not sure how you are doing branching, but I just do the integrate, commit part. I've never made the branch spec and I've never had to create a workspace to branch (although I may have had to change my view mapping if I've decided to exclude directories in my view). That being said, I haven't done anything with svn so I cannot comment on that aspect.
    – Chance
    Commented Jun 24, 2011 at 19:45
  • 1
    @kevin: You known, whether something "works better" isn't necessarily a function of the number of CLI commands needed to do it. Just a comment of someone who isn't very proficient in neither SVN nor Perforce.
    – Martin Ba
    Commented Jun 25, 2011 at 16:21

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.

  • no comment, but I want to know which of our contractors or managers got to play bikini golf!
    – gbjbaanb
    Commented Jun 21, 2011 at 15:50
  • 5
    I'll admit it, Bikini Golf would probably work on me too.
    – jhocking
    Commented Jun 21, 2011 at 15:54

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.

  • 2
    It's all about defining workflow, centralized or decentralized doesn't matter. Support's job is no easier when trying to comb through 200 branches in the central repo. By and large, companies choose centralized solutions because that's what they're comfortable with. There are no appreciable advantages over a DVCS used with a centralized shared repository.
    – wadesworld
    Commented Jun 23, 2011 at 7:28

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!!


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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.