There are many SCM systems out there. Some open, some closed, some free, some quite expensive. Which one (please choose only one) would you use for a 3000+ developer organization with several sites (some behind a very slow link)? Explain why you chose the one you chose. (Give some reasons, not just "because".)


3000+ developer organization??? I would build my own.

I wouldn't do that!99% of the time, developing an SCM internally is outside of the developers and the company's core expertise. You'll probably end up paying (in developer salaries) more than it would cost to buy a system (you'll also have to keep a dev team for maintenance and bugs).
Why build your own? just why? because you can?Are your needs different from every other development company in the world?No.
David Waters
Try it, and report back :)
Thorbjørn Ravn Andersen
+2  A: 

Any DVCS (BitKeeper, git, Bazaar, Mercurial, etc) because being distributed will cut down the load on the central 'canonical' SCM server. The caveat is that they're fairly new technology and not many people will be familiar with their use.

If you want to stick to the older, centralized model, I'd recommend Perforce if you can afford it, or Subversion if you don't want to pay for Perforce. I'd recommend subversion over CVS because it's got enough features to make it worthwhile but is similar enough that devs who already know CVS will still be comfortable.


Adobe uses Perforce

But isn't Perforce a pessimistic lock (see That is a very bad pattern in a largely distributed organization, at least if you want someone to be able to edit the same file at the same time and be able to resolve the merge later (if needed!).
Vasco Duarte
Perforce does not use pessimistic locking by default. It does support both types of locking described in that article. You can lock files if you really want to, but it is not the default behavior upon checkout.
Can you check in a file you have not locked?
Vasco Duarte
+8  A: 

Git was written for the Linux kernel, which might be the closest example to such a situation you can find public information on.

+4  A: 

I want to say git, but don't think a company of that size is going to be all Linux (Windows support for git still sucks). So go with the SCM that Linux used before git i.e. BitKeeper

I dunno... I use git for windows (with msysGit) and it works nicely. It has a 2GB repo limit at the moment, but I haven't hit that roof yet.
+18  A: 

Having worked at a few companies with 1000+ workers, I've found that by-and-large, they all use Perforce.

I've asked "Why don't you use something else? SVN? Git? Mercurial? Darcs?"- and they've said that (this is the same for all of the companies) - when they made the decision to go with Perforce, it was either that, or SourceSafe, or CVS - and honestly, given those three choices, I'd go with Perforce, too.

It's hard for 'more difficult' version control systems to gain traction with so many people, and a lot of the benefits of DCVS are less beneficial when you have the bulk of your software teams working within 18 feet of one another.

Perforce has a lot of API hooks for developers to use, and for a centralized system, it's got a lot of chutzpah.

I'm not saying that it's the best solution- but I've at least seen some very large companies where Perforce works, and well enough that it's almost ubiquitous.

Curtis Lassam
Sure, if you can only choose Perforce or SourceSafe I'd use Perforce too. Or manual SCM for that matter. SourceSafe is one of the worse SCM I've had the displeasure to work with. However, why perforce instead of CVS?
Vasco Duarte
I think the mentality of large dev shops is also that Perforce is profesionally supported (I too worked for a couple). When the auditors come by they feel uncomfortable saying that their engineering backbone is built on an OpenSource project. Perforce feels safer to people who don't know better.
+1  A: 

I'd use any SCM that does not have pessimistic locking ( mechanisms. Especially because you want people to be able to "edit" the same file at the same time in any sizable project.

Personally I'd choose SVN with some solution for distribution, but since in SVN you only submit what you change (which should be very little for each commit anyway), the network overhead is very small. Also the server load can be handled with more hardware to some point. I have not yet found the ceiling for hardware scaling when using SVN.

Other choices may include "git" which the Linux Kernel people use, but I don't really have any experience with that.

Vasco Duarte
+2  A: 

If you have such a large organization then do not mandate a single specific SCM.

I am sure they are not all working on the same code and it would be worth while to let the teams themselves choose what they are most comfortable with.

(You may need to provide some training so the understand how to choose between Git, SVN, some internal legacy system.)

James Dean
This may be a good choice when developers work in different products. In my case they are all working on the same product (albeit different components). To escape the Conway's law curse (, you want to organize around feature teams => developers need to access the whole code base.
Vasco Duarte
+2  A: 


What I like about perforce say compared to CVS is that the branch management is must more sophisticated (but still reasonably easy) and you don't need to bug a central bureaucracy to create branches/labels and the like. In other words it allows to an individual team (or developer) to manage their source components how they like, before submission to a mainline centrally administered by someone else.

Oh, I'd also say it has one of the best GUIs out there whilst still having a 1st class citizen command-line interface. I normally hate GUIs but theirs works.

P4Win was rock solid. P4V is plain buggy. I'm using a 2008 release of it now, because all newer versions until the latest 2010 release have bugs that make the tool misbehave in our environment.

If they're all working on the same product, probably Perforce.

If there are lots of smaller projects (2 to 50), I'd run several Subversion (SVN) boxes.

Ray Hayes
+1  A: 

Perforce is a decent system, and scales well.

I'm working at an organization of about 5000 employees, and perforce is a fast and efficient system. It scales well, has good branch support, has atomic commits. Each change has a change number that can be used for "software archaeology" and a host of other great features.

Additionally, it has good support for windows, mac and unix, including good command line and has good script support.

I've used CVS before, and it doesn't scale well to groups greater than about 25-50 engineers (mostly because of atomic operations and performance)

Most SCM's have atomic commits (, Perforce is no betterAre you been able to comfortably use Perforce when more than one developer needs to edit the same code? Do you synch commits via email? Since perforce "locks" every checked out file this can be a real problem if code is shared.
Vasco Duarte
+6  A: 

I'd recommend Subversion because it is free and has great integration with most IDEs. For those in the organization who travel or prefer a more distributed model, they can use Git for all their local work but still commit to the SVN repository when they want to share code. This is a great balance between a centralized and distributed system. See Git-SVN Crash Course to get started.

The final and perhaps most important reason to use SVN is TortiseSVN, a Windows client for SVN that makes accessing repositories a right-click away for anyone. At my company, this has proven a great way to give repository access to non-developers.

A year later, I would now recommend Mercurial with TortoiseHG. It is the best combination of Windows support and distributed version control functionality.

git-svn seems to put people into an svn type workflow.
git-svn has some serious problems when used with Windows. The line ending issues could make a grown man cry and unless you've got consistent tools for all users it can be a huge pain. Git on Windows is still generally not polished but it's getting better.
+3  A: 

Do not use CVS!! If you want the CVS model, Subversion is a much better alternative.

+1  A: 

If you mean 3000+ developers wokring on the same codebase, i've got no clue. If you mean working on several hundred projects on different locations and you need to have a standard, I'd go for somethins popular with a massive online user support i.e not something obscure that gives you 10 hits on Google.

Personally I would settle for SVN, I'm on an IT dep with several hundreds of devs and the preferable source control app there is SVN.




I would use bitkeeper. I've used bitkeeper, clearcase, accurev, perforce, subversion, cvs, sccs and rcs, and out of all of those bitkeeper was far and above the best. I've toyed with git and was impressed by its speed, but I thought its UI was a little cumbersome (though that opinion was formed after only using it for a couple of half-days).

bitkeeper has rather clunky looking GUIs but they are exceptionally functional. The bitkeeper command line tools are arguably best-of-breed and its merge capabilities were absolutely fantastic.

What I most liked about bitkeeper (and this is probably true of all distributed systems) is that branches were dirt cheap. Creating branches was a way of life rather than something to dread.

Bryan Oakley

Subversion is easy to scale and split up. Perforce costs thousands of dollars for only a handful of employees, way to expensive, and besides, it offers nothing that subversion does not offer.

Subversion is really easy, better than cvs.

I would have recommended git if only their windows support was better

Trausti Thor Johannsson
Your statement leads me to believe that you 1. have not explored the full Perforce functionality yet (e.g. the whole branch mapping concept is ingenious) and 2. have not yet worked as an integration manager in a large-scale development environment.
I would never ever pick perforce to do anything. Git, Mercur, fossil and more version control systems have much better branching and everything else. I will say to though that Perforce has excellent service. But this is 16 months old comment you are commenting on, which makes me believe you are a troll
Trausti Thor Johannsson

in our company we use alienbrain but we are migrating to Perforce. Perforce has everything you want: it hadles code and data, he integrates tools for continuous integration, it handles local (per developer) repository so you can check-in in your local repository before committing on server.

I vote for Perforce

+5  A: 

First, big NO on CVS. Using CVS in 2008 is like driving a 92 Isuzu Trooper. The only reason they are on the road, and that people spend money to maintain them, is for purely sentimental reasons. CVS is old hat, technology-wise, and you will regret it.

I'd generally steer away from open source tools in that size of a company, too. Subversion is an excellent little tool and is pretty solid, but on the off chance that you go down or run into a bug you were unaware of, the onus is on you to fix it while 3,000 people sit idle. Perforce is cheap when put in that perspective and I highly recommend it.

It surprises me how many people that purport to be SCM professionals go with 'free'. On the surface it looks great to managemnt but when you're under the gun it helps to have a high-quality support team on your side. When you get woken up at 3am on a Sunday because your team in Singapore can't do any work, you won't be thinking 'free' was a good idea.

Source control tools are mission critical, you're talknig about company assets and intellectual property. Do not skimp on source control tools, ever!

Funny you should say that: the fact that it's open source is usually a boon. It means that your company or anyone else *can* fix any bugs which crop up, versus sitting around while the vendor tries to fix it. Anyway, SVN has been out for 8 years now and is regarded as quite stable AFAIK.
How do you recon a vendor can fix a bug in the SCM faster than yourself? A swat team with pre-booking on all flights to all destinations? The "you need someone to fix it for you"-argument does not hold. If I develop software for a living, I surely can fix a bug in my SCM software.
Vasco Duarte
I may be a programmer, but I certainly hope that I don't need to dive into some giant bit of code that I've never seen before to fix an obscure problem! Having a professional technical support team on your side is not something to be shrugged off so lightly.
Matt Dillard
A versioning filesystem like zfs underneath the source repository might not be a bad idea (in addition to backups). If the source repository breaks, just find a filesystem snapshot where it was ok. When THAT is said - every release which has gone to a customer should have a build server artifact containing the exact source used to build that code.
Thorbjørn Ravn Andersen
It might be helpful to cite any actual occasions where someone was woken up at 3am to help work around a bug in Subversion. This seems very unlikely to happen. Same with git.
+1  A: 

If you have 1000+ developers working on a single piece of software, you have the resources to invest in a lot of tooling of your own. Whatever you choose, you'll probably do plenty of work to adapt it to your situation.

Microsoft's Team Foundation Server is used within Microsoft on some very large teams, and the TFS team is working on making it scale up well. Also, the integration of source control & bug tracking is attractive. It's not cheap, and administration is enough of a hassle that it doesn't scale down well to small teams, but for your situation, you can afford those costs. You probably also want to be able to call on a large support organization like Microsoft has when you get in to trouble (but if you go with free software, then you have the option of doing that support in-house).

If you have 1000+ engineers in your company, but they are working on pieces of software that ship separately, I think you'd want to put each one on its own server. This makes performance scale better, as well as administration. I would insist on having just one technology for source control, however.

Jay Bazuzi
MS tools only work if you develop for windows _only_. Most of the developers out there in the world do not have that luxury. Cross-platform support is here to stay...
Vasco Duarte

I would actually check out Team Foundation Server. It is a very good system that can scale and it is probably easy to get through internal it departments. I know it is Windows centric but you can use add-ons for Linux/Mac also and you can use proxies for some sites with slow connections.

And I would think about having 2 systems in a large organization, it may help getting the best in some separate cases.


Perforce and TFS are the only options that I know of. I know that both of them have been used on large scale projects within Microsoft. Vault may scale that big, but I don't know if it goes beyond 500-1000 users.

Charles Graham
+1  A: 

Perforce is proven to be scalable to 5000+ users on a single server at Google, see: Life on the Edge: Monitoring and Running a Very Large Perforce Installation

It would seem that many of the largest software companies use Perforce either exclusively or as their main SCM. For example: Adobe, Cisco, SAP, Symantec, EA, UbiSoft and Autodesk are all Perforce users. It's not perfect but it's still superior to SVN or TFS (Neither of which is bad in it's own right)

I take issue with that last statement. You have not explained why Perforce is "superior". If you look at it from a largely distributed team that needs to edit the _same_ code, Perforce is certainly NOT superior in any way. See "Pessimistic Locking".
Vasco Duarte
Sorry, but do believe you are wrong on the locking issue. Perforce only enforces pessimistic locking on text files if you explicitly tell it to, all binaries are pessimisticly locked by default, you can also define a list of file types that will be pessimisticly locked upon open. The file list is flexible down to the file level.
+1  A: 

Perforce gets my vote as well. I've not used it on such large projects, but it's absolutely rock solid in my environment. It also has an impressive resume of large projects, as well.

[rumor]I've heard tell that Microsoft used it for Vista.[/rumor] Apparently it was a customised version for them, but it doesn't get much bigger than that.

Adam Ruth
Microsoft used Source Depot, which is a Microsoft-specific cousin of Perforce.

SVN with TortiseSVN (on Windows) is superb. I highly recommend it.


I'm a Subversion fan but there are a lot of good open and closed source choices. I'd avoid CVS as it really doesn't stack up as a modern SCM (no atomic commits and such).

Someone will probably suggest SourceSafe. Avoid it like the plague. SourceSafe silently destroys history and causes no end of grief. A little googling will tell you more about that.

Subversion is mature and has a lot of good tools and IDE integration. It works well on most networks since it uses HTTP to access the repository.

I worked on a SCM conversion a couple of years ago and the best thing you can do is try them out. SCM vendors will give you demos and tech support for your evaluation.

Choosing a SCM is not an easy thing to do. It really depends on your codebase and workflow. Some systems handle huge codebases better then others. Some handle lot's of branches and merges better then others. Some are better for remote access then others. Some have more fine grained security models.

Get everybody who will interact with the system together and make a list of what you need/want. Get the demos and import your code into it and try it out. Choosing a SCM for a group that large is a major project and should be treated as such.


I would use Subversion. Subversion has been proven on many large, distributed, open-source projects with large developer communities. Also, the transactional nature of Subversion commits makes it ideal for situations where the connection may not be reliable.

  • For a single project (a project which does not depend on other internal project and can deploy all by itself): Subversion
  • For multi-projects environments (when several projects are developed by several teams and must be deployed together on a same platform): ClearCase UCM
    UCM is a methodology which provide some policies for labeling, branching and merging workflow, and facilitate the factorization of a common configuration -- list of labels -- within one given team. It does not solve all problems by far, but for parallel development of several projects, it is a very solid foundation.
+37  A: 
Good thorough answer. However, you did not address the issue of Large Distribution. Some teams are behind a slow link and would work faster if the network latency would be avoided.
Vasco Duarte
SVN was designed to work using slow network connections. I have to use dial-up sometimes and it works well, its compressed diff-based system used to transfer data is efficient.
I should add that it also works really well over a nice fat pipe :)
I used to think SVN worked well with slow network connections...until I used Git :)
+1  A: 

I would use AccuRev. I've used svn, cvs, clearcase (base, ucm), ccc/harvest, but none of them can beat AccuRev's strengths. "3000+ developer organization with several site"? you can use Accurev distributed solution (AccuReplica) for that - which mean you have one single master server and as many as you want replicas on remote sites (so those with the "slow link" won't suffer much)

Above all AccuRev brings a unique approach - a truly new concept/design/implementation of stream-based SCM tool. Not in the (bad) way ClearCase-UCM did that (because ClearCase "streams" were eventually branches), but in slick modern way.

The best is to try it yourself, I know that they offer a trial of 30 days with enough licenses to toy with the tool - try it and you won't want to consider other tools. My promise.


Have to wholeheartedly agree with not using CVS. For really large numbers of developers I would suggest using Perforce. For lower numbers, Subversion or TFS.

Mitch Wheat
nice one Ande - how transparent
Mitch Wheat

I'd highly recommend SVN with TortiseSVN client and Visual-SVN add-on for developers using Visual Studio.

+1  A: 

I doubt whether you have 3000 developers in your organisation all working on the same code base. I work for a medium-large software company, and we probably don't have that many in the entire company, but there are also many independent projects.

Internally some groups deliver releases to other groups to use in their products; this is not managed through a SCM system.

Our own group has its own SCM but there are only about 25 active developers. We use CVS, and to be quite honest it's not really up to it (we'd migrate but have a lot of scripts / commit hooks and other bits & pieces which need a lot of work to change). The problem with using CVS on a reasonable size code base is that many operations are very slow and involve locking other developers out.

+2  A: 

Okay, outright disclaimer: I'm a developer for a company called MKS which makes a version control system for "enterprise" companies as part of a software configuration management platform called Integrity. Blah blah blah, obvious plug.

So I can't honestly answer the question.

However, I'd like to point out that people suggesting distributed version control are missing something screamingly important for large companies. For them, it's less important how much flexibility developers have when dealing with their version control system than it is that they have absolute control over every line of code that gets shipped. Regulatory conformance and audits are a way more central concern than how painful merges are.

A company with 1000+ developers wants to know that everybody is doing what they're supposed to do and that nobody is doing what they're not supposed to do, everything is tracked and managers get lovely reports and graphs they can paste into PowerPoint slides for their managers.

If a large company doesn't particularly care about those things, they're far more likely to leave it up to individual dev teams to figure out their own thing, in which case, 1000+ developers are using a hodge-podge of different tools based on whatever seemed most convenient at the time.

Darcy Casselman
@Darcy You can enforce regulatory conformance and audits on a DVCS. Practically you have a central repository that a commite pulls in changes to from proposed patches. Those 1000+ developers can then have their own repository without littering the central one and still have the benefit of DVCS.
That is also how most well organized OSS developers work. You can't beat how the whole world works compared to measly 3000+. ;)
It's not so much a technical limitation as a mindset difference. In some cases, we're talking about *very* restricted environments. The word "distributed" in those situations alone is enough to scare these people off.
Darcy Casselman
Only code build by the build server can go to the customer...
Thorbjørn Ravn Andersen
I know that and you know that, but we're not the ones who are scared. These people aren't developers. These are people who are very concerned about things like traceability and auditory compliance. People promoting DVCSes need to speak their language.
Darcy Casselman
+1  A: 

Let's see the options.

1 - Perforce. Used by lots of companies (as people said there) Adobe, Amazon, MS, Google Companies who grew, advanced, and depend on selling software everyday to put food on the table, that's their choice. I guess that's the way I would go if I needed a supported "global solution" for a multitude of sites, etc Good for Win/Linux (not sure about Macs though)

2 - SVN. Used by big teams as well, KDE uses it (huge, huge project) currently in revision 880,000 (yes!) Very practical for both Windows and Linux usage (even though I would call TortoiseSVN below average in some aspects) Commercial support can be contracted as well. Good for Windows / Linux / Macs as well.

3 - Accurev If I was trying to be "edgy". I wouldn't deploy it on the whole company without some testing and getting used to it first.

4 - MS Team Foundation It may be a good solution but I never tried and is probably Windows only.

5 - Git / Bzr / Hg - Bzr and Hg have their "tortoises" so, good for Windows (even though I'm not sure about maturity) Git would be linux only for the time being, even though it is VERY GOOD (and much better and easier to use than a couple of years ago).

I would NEVER, EVER, ABSOLUTELY No WAY JOSE use Clearcase. PERIOD It is a waste of everybody's money and time and sanity.

Steer clear of: CVS / Clearcase / anything older