Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

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

share|improve this question

migrated from stackoverflow.com Jun 21 '11 at 14:47

This question came from our site for professional and enthusiast programmers.

closed as not constructive by Matthieu, Mark Trapp Jan 28 '12 at 19:45

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

27  
I heard Google uses timestamp-named folders on a shared drive! ;) –  FrustratedWithFormsDesigner Jun 21 '11 at 14:50
9  
Only the shared drive uses MapReduce, so they are cool –  Paul Stovell Jun 21 '11 at 15:28
3  
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 Jun 21 '11 at 16:30
10  
@Anto: Who cares what Linus says? Just because you're a brilliant kernel developer does not mean you know best about everything everwhere. –  Billy ONeal Jun 21 '11 at 19:33
4  
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 Jun 22 '11 at 1:26
show 10 more comments

15 Answers

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.

share|improve this answer
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. –  Greg Jackson Jun 21 '11 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 Jun 21 '11 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 Jun 21 '11 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 Jun 21 '11 at 21:23
7  
@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 –  Alex Feinman Jun 23 '11 at 14:14
show 9 more comments

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.

share|improve this answer
5  
Summed up you've just said "There are reasons to choose Perforce, but I'm not telling you." –  edA-qa mort-ora-y Jun 21 '11 at 15:54
1  
Why are these comments and not edits? Your answer is comment worthy and your comments are answer-worthy :\ –  Brendan Long Jun 21 '11 at 17:35
1  
@Brendan: Fair enough! –  Bob Murphy Jun 21 '11 at 18:12
1  
The answer is much better with the tl;dr bits added. -1 to +1. –  Mark Booth Jun 24 '11 at 11:03
1  
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 Feb 12 '13 at 7:29
show 3 more comments

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.

share|improve this answer
4  
+1. We switched to git relatively recently, and had to run perforce for rather long time — just because everything else was inferior. –  9000 Jun 21 '11 at 16:38
10  
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 Jun 21 '11 at 18:44
1  
Perforce and ignorant developers made me hate checking in code. I would rather write code with crayon and compile that. –  Jim Schubert Jun 21 '11 at 23:08
add comment

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.
share|improve this answer
13  
I think "old" developers (+10 years) are probably as resistant to change as "non-technical" people. –  Wayne Werner Jun 21 '11 at 17:46
    
That's probably true. I only recently switched from P4Win to P4V, and that's just changing the GUI, not the entire system. And I know plenty of other holdouts who still haven't switched, despite P4Win being deprecated for some time now. –  Mike O'Connor Jun 21 '11 at 18:08
2  
+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. –  Chris Subagio Jun 22 '11 at 16:06
    
To add another perspective, when I worked as an indie games dev we used git all revision control, even art assets (separate module). –  RJFalconer Apr 1 at 14:34
    
I'd be hesitant to group people into technical/non-technical - is git really more complex than Maya/Photoshop? I'd wager with a bit of training and perhaps some tooling they'll be submitting to git in no time. –  RJFalconer Apr 1 at 14:35
add comment

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.

share|improve this answer
20  
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? –  Sverre Rabbelier Jun 21 '11 at 21:02
    
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 Jun 21 '11 at 21:23
    
I got Hudson working with Perforce in less than 6 hours with never having used Hudson before. I did not use checkin hooks as it seemed to easy to take down the server so I just had Hudson poll Perforce for the repos that I cared about on a regular basis (every 10 min or so). That being said Mercurial hooks are really easy to use and so hg pushes trigger Hudson builds. My point is that Hudson will work with just about anything. –  stephenmm Mar 20 '12 at 19:39
4  
@SverreRabbelier 3 years later, and there are still people waiting for an answer to your question. –  Navin Feb 28 at 20:27
1  
"because Perforce is better" ... "This isn't a football game where one team is better than another". ... –  RJFalconer Apr 1 at 14:40
show 1 more comment

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.

share|improve this answer
    
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 Jun 21 '11 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 Jun 21 '11 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 Jun 21 '11 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 Jun 21 '11 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. –  kevin cline Jun 21 '11 at 19:40
show 3 more comments

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.

share|improve this answer
12  
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 Jun 21 '11 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 Jun 21 '11 at 15:34
7  
Google isn't really known for this sort of culture. –  Jeremy Jun 21 '11 at 16:02
3  
If they're not renting you your own, personal stripper...you're not a hard enough sale. –  Crazy Eddie Jun 21 '11 at 16:22
9  
@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. –  Tom Anderson Jun 21 '11 at 17:47
show 22 more comments

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.

share|improve this answer
4  
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 –  M. Dudley Jun 21 '11 at 16:34
1  
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. –  kevin cline Jun 21 '11 at 19:41
    
@kevin, depends on whether you are doing a "light" branch (server only), which is certainly faster on Subversion, or a "heavy" branch (client and server) which can be an order of magnitude faster on Perforce. (propaganda here: perforce.com/perforce/comparisons/perforce_subversion.pdf ). Perforce does actually do branching fairly intelligently, and can be faster in some cases due to the difference in the delta mechanism used. –  JasonTrue Jun 21 '11 at 21:09
    
@emddudley: Nice link. As I said: "Everything is local" is exactly not what I want from my company's VCS. YMMV. As for "Any Workflow": The question is how hard it is to get running equally well and stable for all devs on all developer machines. How much training needed? But then, your comment "unless ... team is clueless" does seem to indicate you only work with top notch teams and you never have to battle with mule headed devs. ;-) –  Martin Ba Jun 22 '11 at 8:52
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. –  kevin cline Jun 23 '11 at 21:32
show 5 more comments

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.

share|improve this answer
    
no comment, but I want to know which of our contractors or managers got to play bikini golf! –  gbjbaanb Jun 21 '11 at 15:50
5  
I'll admit it, Bikini Golf would probably work on me too. –  jhocking Jun 21 '11 at 15:54
1  
+1 for the way you mention Serena Dimensions. –  starblue Jun 21 '11 at 19:42
add comment

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

share|improve this answer
    
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 Mar 20 '12 at 19:31
add comment

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.

share|improve this answer
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. –  Bruce Ediger Jun 21 '11 at 17:37
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
1  
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 Jun 23 '11 at 7:28
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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