Why big companies use Perforce?
I heard about some big companies e.g. Google, Facebook use Perforce
Are there any reason why SVN/Git cannot replace Perforce?
I heard Google uses SVN :P
I heard Google uses timestamp-named folders on a shared drive! ;)
See http://stackoverflow.com/questions/5683253/distributed-version-control-systems-and-the-enterprise-a-good-mix/5685757#5685757 : it is not as easy as it seems ;)
Some large companies do use SVN. I happen to work at one and we Cancelled some large perforce migration projects in favor of SVN.
IIRC in the talk Linus gave to Google about Git it was mentioned that they use perforce?
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.
@mathepic yes but that was 2007 IIRC. A lot could have changed since then, though I don't know whether it actually has changed or not.
Your question is flawed. Different groups use different tools. I don't know any large corporations that force all their groups to use a certain technology like p4.
@Anto: Who cares what Linus says? Just because you're a brilliant kernel developer does not mean you know best about everything everwhere.
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.
Google is also experimenting with a git bridge (http://www.quora.com/What-version-control-system-does-Google-use-and-why)
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.
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.
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.
I wasn't aware of the history. Out of curiosity, when did that move happen? It's very important for folks to remember that business and technology decisions can't be made in a vaccum, and there's a lot more to take into account than just what the ideal tool might be.
I don't remember for sure; I saw an online source that said the transition happened circa 1999, although I was in a different part of the company at that time. I don't think I encountered Source Depot until quite a bit later, maybe 2001 or 2002.
So definitely before Vista, very possibly with XP. Which means that there's 3-4 major OS releases, plus service packs in SD. Definitely not a trivial thing to move around.
http://discuss.fogcreek.com/joelonsoftware/default.asp?cmd=show&;ixPost=16204 has some of this history from mostly outsider sources. (I've been an outsider since 2004, FWIW).
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. http://maillist.perforce.com/pipermail/perforce-user/2001-August/006640.html and http://subversion.apache.org/docs/release-notes/release-history.html
@gbjbaanb, that's not a large repository...these days it counts as a medium-sized one. ;) See e.g. http://research.google.com/pubs/archive/34459.pdf
Yep, I have a partial enlistment (defintely < 50%) for a single branch that's over 30GB. I've got equivalent enlistments for 8 other branches on my dev box. We have many branches across several different products. A 12GB repository is small beans, considering I've got 20x that just mapped on my dev box.
https://www.usenix.org/legacy/events/usenix-win2000/invitedtalks/lucovsky_html/index.htm says that for NT this move was done just before Win2000 RTMed. I wonder when Office, VS, etc moved.
**SmartGit/Hg** is a nice piece of software is GUI what keeps you back though. And it's priced really nice. (Compared to what a P4 server license costs.) Not an ad, I found it here in a comment or answer months ago, and been using it since then.
I just want to add another data point: Intel is a fairly large company. The RTL design database for Intel CPUs is pretty large. For many years Intel's RTL design community was/has been a big supporter of DVCS - amongst other things, Intel was a big paid customer of BitKeeper for years, and more recently was a big user of git. (I left Intel in 2009, so things may have changed.)
"Distributed" was the big reason Intel adopted DVCSes like BitKeeper and git. Intel RTL work is split geographically: California/Oregon/Israel/Texas/India/... Networks are great, but unfortunately they still sometimes break, get slow, etc. DVCSes mean that different teams using the same source code base can make progress even when disconnected. Perforce, fundamentally, is a centralized version control system. P4 has features like sandboxes that are semi-distributed, but AFAIK are not all the way there.
At Intel, the really big projects, especially multiple projects using shared code bases, geographically dispersed, used DVCSes like BitKeeper and git. The projects that really made money. Smaller projects, typically software projects used Perforce or something else (SVN, CVS, ...). Perforce evangelists often tried to convert the RTL/DVCS teams - and then were flabbergasted by the requirements and scale. Projects using Perforce often penalize folks working far away from the central server.
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.
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: 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.
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.
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.
+1. We switched to git relatively recently, and had to run perforce for rather long time — just because everything else was inferior.
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.
Perforce and ignorant developers made me hate checking in code. I would rather write code with crayon and compile *that*.
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.
I think "old" developers (+10 years) are probably as resistant to change as "non-technical" people.
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.
+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.
To add another perspective, when I worked as an indie games dev we used git all revision control, even art assets (separate module).
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.
@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.
@JamesAnderson You may be right. I'm pretty sure that when _I_ am over sixty I'll also be pushing my organization to change and improve. Though, I'm pretty sure I've seen research that says as people age they become more risk averse, and hence resistant to change. But maybe there *is* an equal portion of new developers and old developers with the same resistance to change.
@Wayne Werner -- I find its more a matter of the size and age of the organization. The bigger a department and the longer it has been around you find the "I'll stay here cause I can't get a job anywhere else" syndrome takes its toll.
@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.
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:
- You run an open source project. Would you be happy or upset if a million people had a copy of your entire repository?
- 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.
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?
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).
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.
@SverreRabbelier 3 years later, and there are still people waiting for an answer to your question.
Why exactly does using p4 not mean that thousands of people have a copy of your repository? Each developer still needs a copy of the code on their local disk. This is no less risky than a git local working branch.
"because Perforce is better" ... "This isn't a football game where one team is better than another". ...
perforce is fast. much faster than svn or git. --- benchmarks, or it did not happen... ;p
Regarding support - agreed that perforce will have a team to offer you support, but the with open source tools like git, you will find that the internet is littered with problem/solution forums. A simple google search might suffice for GIT, mainly because people using them use googling/forums, etc. to resolve their problems, so in time the knowledge base gets built up, and that's quite sufficient. I have never come across a git issue for which I couldn't find a solution online - though I would confess I have never used git for extremely large projects.
Also, you can do sparse checkout with git as well, although it isn't as easy as in Perforce, since Git anyway populates its whole index, and then copies the required files to working directory. Basically even with sparse checkout you end up downloading entire repository in Git.
Google uses Perforce under the hood because Git is too slow. This is in 2017.
Anyone who's ever used Perforce and Git LFS knows that Perforce's speed with binary content is hugely faster. For just fetching or submitting text content, most people won't notice a speed difference. But the minute you start including binary in the comparison, and especially LFS, Git can't even begin to compare.
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.
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.
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.
I don't understand why this answer was upvoted, it attempts to explain the situation by citing trivial stereotypes. Can you get support for Git installations?
@quant_dev As Homer says, "it's funny, because it's true." There are other questions that cover git in enterprise and there are lots of companies that offer commercial support for Git. Hey, I'm one!
@Jeremy As far as I know, Google has not been at all resistant to Git Google uses Mercurial at least for Google Code, which is likewise FOSS.
@mathepic As much as it sullies my reputation as a brainless git-fanboy, I have to admit that there are issues with Git and http integration; Mercurial, its advocates maintain, with some justice, runs better over http. But if all you use is ssh, like me, Git is the clear winner.
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.
@Dmitri Which just proves my point - They both have advantages. Why not allow for both?
@mathepic I don't know, they had to pick just one? Besides, they offer nice tutorrials on how to use Git with Google Code.
@mathepic At the time of initial implementation, Mercurial's efficient HTTP support integrated better with Google's preexisting architecture than Git did. http://code.google.com/p/support/wiki/DVCSAnalysis
@Dmitri They don't though. They offer SVN as well, so its not like their system only supports one.
While FOSS tools have a large community base from which to draw help, one thing I do like about Perforce is I dial tech support and I'm talking to a human in less than a minute. First year is a little expensive but $160/user for following years is not overwhelming for our particular company. Perhaps there is something similar with git, I don't know, but at the time I was selecting tools, I only knew of Subversion and CVS as FOSS tools.
@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, looking through my emails (while I like being able to call them I usually send emails), someone actually deleted their shelved files and I wanted to know how to retrieve them, some questions on triggers and who has permission to run them, problems with the visual client running slowly, a couple feature requests for the merge tool, a problem with my depot to client mapping (one I called for).
@Tom, the most complicated issues have been triggers and depot to client mapping. If those tools do those things better or solve the problem in a different way that's definitely a plus for them. Perforce needs some improvement concerning ease of use in those areas.
Maybe we need strippers to volunteer to promote FOSS to big companies... as they say, you don't have to write code to contribute to open source
@JoelFan: Ceren Ercen did something at least comparable for FreeBSD. I'm not sure DVCSs generate quite as much passion as the pioneering free operating system, though. Hmm; maybe Mark Shuttleworth would bankroll a once-and-for-all Git vs Mercurial roller derby smackdown decider?
@Chance: Thanks for the details. I've never used, let alone wrangled, Perforce, so i can't really comment on how well Mercurial deals with those situations. If triggers are the same as hooks, then those are reasonably straightforward; they're shell scripts with defined environment variables, or Python functions run against a documented API. Mercurial being decentralised, they run on the machine where the repository is, as the user making the action. As for mapping, AIUI, that's something that doesn't exist with Mercurial; you'd use multiple repositories (perhaps as subrepositories) for that.
@Dmitri, But what @Jeremy's referring to is the fact that Google still uses Perforce **internally** for all of their source code.
Perforce doesn't have salesmen and doesn't do the wine and dine thing. They go strictly by their published price list at http://www.perforce.com/perforce/price.html
@Tom Anderson: I remember a situation where we had to call support for Rational ClearCase (8 years ago) - it somehow corrupted all our XML files with localized texts and it stopped accepting them on commits. Technical support spent few very long nights with solving the problem including cooperation with their own developers.
@Tom, @Ladislav's comment brings to mind another advantage of human technical support, having someone available in emergency situations. Sometimes it may not be the software's fault (although I wouldn't be surprised with ClearCase), but sometimes an admin may be staring at corrupted or missing files. I was in a situation where we were missing our past 6 months of revision history all of a sudden and I needed answers fast (it turned out that we started the wrong instance of Perforce in an old directory, although we ended up finding out the problem ourselves).
I thought this would have been a good answer, but it went a little too much toward "There's NOTHING any commercial tool offers that a FOSS tool doesn't, and the ONLY reason anyone would every pick Perforce is because they are stuck with it or their sales staff got the CIO drunk."
@Chance : you might have misread what I meant. I wrote, "no *functional* advantage," meaning that there are no major software features that commercial version systems have that haven't been implemented in a FOSS system. If you can think of one, I would love to know. Though I am afraid that my "wine and dine" humor might have been lost on some of the more linear-thinking members of this community. I doubt that there is enough booze in Scotland to, say, get Google to switch to VSS. Not even Microsoft, reportedly, will eat that dog food.
@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: http://www.perforce.com/git
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.
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 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.
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.
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.
@Jeremy: I know its not nearly as bad as it was, but it is still less than favourable. Take a look at Perforce's customer list and think, how many of them could be using SVN? Now take a less good SCM provider and see their customer bases.
@kevin, are you speaking to modifying current files or adding/deleting files? I've found modifying files pretty easy, `chmod +w` then do a `p4 edit` later. Reconciling added files can be a pain, however, due to object files polluting the workspace.
Actually, most businesses I've worked with loved FOSS because of the "free" thing.
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.
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.
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
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.
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.
You can use Git just fine with different workflows, so being _distributed_ is not an issue... unless the company team is clueless. http://whygitisbetterthanx.com/#any-workflow
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, 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: http://www.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.
@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. ;-)
@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, 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 - http://kb.perforce.com/?article=4 says that branching is a four step process, involving manual editing of both the client spec and creation of a branch spec.
@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 - With years of experience on both Perforce and SVN, there is no question in my mind which is easier to use. Perforce may be faster for some operations. Branching isn't one of them.
@kevin, as I said, manual editing of the client spec may be necessary - this is if a user has changed their view mapping from the default, where they don't see every file (I don't know how common this is). Creating a branch spec isn't necesssary; I haven't done it for the 3.5 years I've used Perforce.