<p>There are many SCM systems out there. Some open, some closed, some free, some quite expensive. Which one <em>(please choose only one)</em> 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".)</p>

[{'answer_id': 65472, 'author': 'pjz', 'author_id': 8002, 'author_profile': 'https://Stackoverflow.com/users/8002', 'pm_score': 2, 'selected': False, 'text': "<p>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.</p>\n\n<p>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.</p>\n"}, {'answer_id': 65484, 'author': 'Peldi Guilizzoni', 'author_id': 1199623, 'author_profile': 'https://Stackoverflow.com/users/1199623', 'pm_score': 0, 'selected': False, 'text': '<p>Adobe uses Perforce</p>\n'}, {'answer_id': 65496, 'author': 'ceejayoz', 'author_id': 1902010, 'author_profile': 'https://Stackoverflow.com/users/1902010', 'pm_score': 3, 'selected': False, 'text': '<p>Git was written for the Linux kernel, which might be the closest example to such a situation you can find public information on.</p>\n'}, {'answer_id': 65533, 'author': 'Sijin', 'author_id': 8884, 'author_profile': 'https://Stackoverflow.com/users/8884', 'pm_score': 3, 'selected': False, 'text': '<p>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. <a href="http://www.bitkeeper.com/Products.html" rel="nofollow noreferrer">BitKeeper</a></p>\n'}, {'answer_id': 65562, 'author': 'Curtis Lassam', 'author_id': 9337, 'author_profile': 'https://Stackoverflow.com/users/9337', 'pm_score': 4, 'selected': False, 'text': '<p>Having worked at a few companies with 1000+ workers, I\'ve found that by-and-large, they all use Perforce.  </p>\n\n<p>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.</p>\n\n<p>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. </p>\n\n<p>Perforce has a lot of API hooks for developers to use, and for a centralized system, it\'s got a lot of chutzpah. </p>\n\n<p>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. </p>\n'}, {'answer_id': 65631, 'author': 'Vasco Duarte', 'author_id': 9362, 'author_profile': 'https://Stackoverflow.com/users/9362', 'pm_score': 1, 'selected': False, 'text': '<p>I\'d use any SCM that does not have pessimistic locking ( <a href="http://old.davidtanzer.net/?q=node/118" rel="nofollow noreferrer">http://old.davidtanzer.net/?q=node/118</a> ) mechanisms. Especially because you want people to be able to "edit" the same file at the same time in any sizable project.</p>\n\n<p>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.</p>\n\n<p>Other choices may include "git" which the Linux Kernel people use, but I don\'t really have any experience with that.</p>\n'}, {'answer_id': 65671, 'author': 'Jeroen Dirks', 'author_id': 7743, 'author_profile': 'https://Stackoverflow.com/users/7743', 'pm_score': 1, 'selected': False, 'text': '<p>If you have such a large organization then do not mandate a single specific SCM.</p>\n\n<p>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.</p>\n\n<p>(You may need to provide some training so the understand how to choose between Git, SVN, some internal legacy system.)</p>\n'}, {'answer_id': 65847, 'author': 'tonylo', 'author_id': 4071, 'author_profile': 'https://Stackoverflow.com/users/4071', 'pm_score': 1, 'selected': False, 'text': "<p>Perforce</p>\n\n<p>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.</p>\n\n<p>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.</p>\n"}, {'answer_id': 65972, 'author': 'Ray Hayes', 'author_id': 7093, 'author_profile': 'https://Stackoverflow.com/users/7093', 'pm_score': -1, 'selected': False, 'text': "<p>If they're all working on the same product, probably Perforce.</p>\n\n<p>If there are lots of smaller projects (2 to 50), I'd run several Subversion (SVN) boxes.</p>\n"}, {'answer_id': 65983, 'author': 'mike511', 'author_id': 9593, 'author_profile': 'https://Stackoverflow.com/users/9593', 'pm_score': 0, 'selected': False, 'text': '<p>Perforce is a decent system, and scales well.</p>\n\n<p>I\'m working at an organization of about 5000 employees, and perforce is\na fast and efficient system.  It scales well, has good branch support,\nhas atomic commits. Each change has a change number that can be used\nfor "software archaeology" and a host of other great features.</p>\n\n<p>Additionally, it has good support for windows, mac and unix, including\ngood command line and has good script support.</p>\n\n<p>I\'ve used CVS before, and it doesn\'t scale well to groups greater than\nabout 25-50 engineers (mostly because of atomic operations and performance)</p>\n'}, {'answer_id': 66332, 'author': 'Lanny', 'author_id': 9127, 'author_profile': 'https://Stackoverflow.com/users/9127', 'pm_score': 3, 'selected': False, 'text': '<p>As of 2015, the most important factor is to use a <em>Distributed</em> Version Control System (DVCS). The main benefit of using a DVCS: allowing source code collaboration at many levels by reducing the friction of source code manipulation. This is especially important for a 1000+ developer organization.</p>\n\n<h3>Reducing Friction</h3>\n\n<p>Individual developer checkins are decoupled from collaboration activities. Lightweight checkins encourage clean units of independent work at a short-time scale (many checkins per hour or per day). Collaboration is naturally handled at a different, usually longer, time-scale (sync with others daily, weekly, monthly) as a system is built up in a distributed organization.</p>\n\n<h3>Use Git</h3>\n\n<p>Of the DVCS options, you should likely <em>just use <a href="http://git-scm.com" rel="nofollow noreferrer">Git</a></em> and take advantage of the great communities at <a href="https://github.com" rel="nofollow noreferrer">GitHub</a> or <a href="https://bitbucket.org" rel="nofollow noreferrer">Bitbucket</a>. For large private organizations, <em>internal community</em> and <em>internal source code hosting</em> may be important (there are vendors selling private hosting systems such as <a href="https://www.atlassian.com/software/stash" rel="nofollow noreferrer">Atlassian Stash</a> and probably others).</p>\n\n<p>The main reason to use Git is that it is the most popular DVCS. Because of this:</p>\n\n<ul>\n<li><p>Git is well-integrated into a wide range of development toolchains</p></li>\n<li><p>Git is known and used by most developers</p></li>\n<li><p>Git is <a href="http://git-scm.com/documentation" rel="nofollow noreferrer">well-documented</a></p></li>\n</ul>\n\n<h3>Or Mercurial</h3>\n\n<p>As an alternate to Git, <a href="http://www.selenic.com/mercurial/" rel="nofollow noreferrer">Mercurial</a> is also very good. Mercurial has a slightly cleaner, more orthogonal set of commands than Git. In the late 2000\'s, it used to be better supported than Git on Windows systems mostly due to having core developers that cared more about Windows.</p>\n\n<h3>GUI</h3>\n\n<p>For those who would like to use a GUI instead of <code>git</code> and <code>hg</code> on the command line, <a href="http://www.sourcetreeapp.com" rel="nofollow noreferrer">SourceTree</a> is a great Windows and OS X application that presents a clean interface to both Git and Mercurial.</p>\n\n<h3>Obsolete Recommendations</h3>\n\n<p>As of 2010, I recommended <a href="http://www.selenic.com/mercurial/" rel="nofollow noreferrer">Mercurial</a> with <a href="http://bitbucket.org/tortoisehg/stable/wiki/Home" rel="nofollow noreferrer">TortoiseHG</a>. It is the best combination of Windows support and distributed version control functionality.</p>\n\n<p>From 2006-2009, I recommended <a href="http://subversion.tigris.org/" rel="nofollow noreferrer">Subversion</a> (SVN) 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 <a href="http://git.or.cz/course/svn.html" rel="nofollow noreferrer">Git-SVN Crash Course</a> to get started. The final and perhaps most important reason to use SVN is <a href="http://tortoisesvn.tigris.org/" rel="nofollow noreferrer">TortoiseSVN</a>, 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.</p>\n'}, {'answer_id': 66456, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 2, 'selected': False, 'text': '<p>Do not use CVS!! If you want the CVS model, Subversion is a much better alternative.</p>\n'}, {'answer_id': 66812, 'author': 'Wiren', 'author_id': 2538222, 'author_profile': 'https://Stackoverflow.com/users/2538222', 'pm_score': 0, 'selected': False, 'text': "<p>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.</p>\n\n<p>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.</p>\n\n<p>:)</p>\n\n<p>//W</p>\n"}, {'answer_id': 66873, 'author': 'Bryan Oakley', 'author_id': 7432, 'author_profile': 'https://Stackoverflow.com/users/7432', 'pm_score': 1, 'selected': False, 'text': "<p>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).</p>\n\n<p>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.</p>\n\n<p>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.</p>\n"}, {'answer_id': 66935, 'author': 'Trausti Thor', 'author_id': 6801, 'author_profile': 'https://Stackoverflow.com/users/6801', 'pm_score': -1, 'selected': False, 'text': '<p>Subversion is easy to scale and split up.\nPerforce costs thousands of dollars for only a handful of employees, way to expensive, and besides, it offers nothing that subversion does not offer.</p>\n\n<p>Subversion is really easy, better than cvs.</p>\n\n<p>I would have recommended git if only their windows support was better</p>\n'}, {'answer_id': 67228, 'author': 'ugasoft', 'author_id': 10120, 'author_profile': 'https://Stackoverflow.com/users/10120', 'pm_score': -1, 'selected': False, 'text': '<p>in our company we use alienbrain but we are migrating to Perforce.\nPerforce 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.</p>\n\n<p>I vote for Perforce</p>\n'}, {'answer_id': 67301, 'author': 'Mattyj', 'author_id': 10180, 'author_profile': 'https://Stackoverflow.com/users/10180', 'pm_score': 2, 'selected': False, 'text': "<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>Source control tools are mission critical, you're talknig about company assets and intellectual property. Do not skimp on source control tools, ever!</p>\n"}, {'answer_id': 67402, 'author': 'Jay Bazuzi', 'author_id': 5314, 'author_profile': 'https://Stackoverflow.com/users/5314', 'pm_score': 1, 'selected': False, 'text': "<p>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.  </p>\n\n<p>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 &amp; bug tracking is attractive.  It's not cheap, and administration is enough of a hassle that it doesn't scale <em>down</em> 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).</p>\n\n<p>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.</p>\n"}, {'answer_id': 67821, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 0, 'selected': False, 'text': '<p>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.</p>\n\n<p>And I would think about having 2 systems in a large organization, it may help getting the best in some separate cases.</p>\n'}, {'answer_id': 67871, 'author': 'Charles Graham', 'author_id': 7705, 'author_profile': 'https://Stackoverflow.com/users/7705', 'pm_score': 0, 'selected': False, 'text': "<p>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 <em>may</em> scale that big, but I don't know if it goes beyond 500-1000 users.</p>\n"}, {'answer_id': 67981, 'author': 'Ausmith1', 'author_id': 10490, 'author_profile': 'https://Stackoverflow.com/users/10490', 'pm_score': 0, 'selected': False, 'text': '<p>Perforce is proven to be scalable to 5000+ users on a single server at Google, see:\n<a href="http://www.perforce.com/perforce/conferences/us/2007/presentations/DBloch_Life_on_the_Edge2007_paper.pdf" rel="nofollow noreferrer">Life on the Edge: Monitoring and Running a Very Large Perforce Installation</a></p>\n<p>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)</p>\n'}, {'answer_id': 68062, 'author': 'Adam Ruth', 'author_id': 10262, 'author_profile': 'https://Stackoverflow.com/users/10262', 'pm_score': 0, 'selected': False, 'text': "<p>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. </p>\n\n<p>[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.</p>\n"}, {'answer_id': 68089, 'author': 'andyc', 'author_id': 313475, 'author_profile': 'https://Stackoverflow.com/users/313475', 'pm_score': -1, 'selected': False, 'text': '<p>SVN with TortiseSVN (on Windows) is superb. I highly recommend it.</p>\n'}, {'answer_id': 68098, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': -1, 'selected': False, 'text': "<p>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).</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>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.</p>\n"}, {'answer_id': 68273, 'author': 'KeithL', 'author_id': 5478, 'author_profile': 'https://Stackoverflow.com/users/5478', 'pm_score': -1, 'selected': False, 'text': '<p>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. </p>\n'}, {'answer_id': 71094, 'author': 'SAL9000', 'author_id': 11609, 'author_profile': 'https://Stackoverflow.com/users/11609', 'pm_score': 5, 'selected': False, 'text': '<ul>\n<li>For such a huge installation, there are at least the following major requirements: <strong>Data safety</strong>, maturity, robustness, <strong>Scalability</strong>, <strong>price</strong> (a per seat licence vs. open source always makes a huge difference regardless of the price per seat), ease of administration</li>\n<li>I would think that <strong>subversion</strong> would be just fine.</li>\n<li>There is <strong>support</strong> available (from <a href="http://www.open.collab.net/products/subversion/" rel="nofollow noreferrer">collabnet</a>, <a href="http://www.clearvision-cm.com/consulting.html" rel="nofollow noreferrer">clearvision</a>, <a href="http://wandisco.com/php/subversion_support.php" rel="nofollow noreferrer">wandisco</a> and others). You could ask them if subversion would be able to handle your task.</li>\n<li>subversion has a very mature database backend - FSFS. It is absolutely rock solid and since 1.5 it can handle really many revisions without performance degradation. The revisions are written in a file system. So the reliability of your subversion repository depends on the quality of your file system, os and storage system.</li>\n<li>This is why I would recommend <strong>Solaris 10 with ZFS</strong> as the file system. ZFS has really great file system features for production systems. But above all it provides data integrity checksumming. So with this amount of source code in the subversion repository you won\'t have to worry about repository corruption because of a silent hard drive bit error or controller or cable bit error. By now ZFS is mature enough that it can be safely used as a UFS or whatever replacement.</li>\n<li>I don\'t know about the hardware requirements. Maybe Collabnet could give you advice.</li>\n<li>But a really good start (which could be used as NFS storage or backup storage if it turns out to be too slow - you will definitely be able to make good use of it anyway) would be a 2nd generation <a href="http://www.sun.com/servers/x64/x4540/" rel="nofollow noreferrer">thumper</a>, i.e <strong>Sun Fire X4540 Server</strong>: You can have (all within a nice 4U Rack Server for 80.000$ (list price - this will be likely negotiable)): 48 TB Disk space!, 8 AMD Opteron CPU cores,  64 GB RAM,  Solaris 10 preinstalled, 3 year Platinum software and hardware support from sun. So the mere hardware and support price for this server would be 25$ per seat of your 3000 Developers.</li>\n<li>To assure really great data safety, you could partition the 48 hard drives as follows: 3 drives for the operating system (3-way Raid-1 mirror), 3 hot spares (not used, on stand-by in the case of a failure of the other drives), a zfs pool of 14 3-way Raid 1 mirrors (14*3=42 drives) for the subversion repository. If you would like to fill the 14 TB ZFS Raid space only by 80% then this would be approximately 10 Tebibyte of real usable disk space for the repository, i.e. an average of 3 GB per developer.</li>\n<li><strong><em>With this configuration: Subversion 1.6 on a Sun x4540 thumper with 10 TiB 3-way Raid-1 ZFS redundant and checksummed disk space this should be a really serious start.</em></strong></li>\n<li>If the compute power isn\'t enough for 3000+ developers than you could buy a beefier server which could use the disk space of the thumper. If the disk performance is too slow you could hook up a huge array of fast scsi drives to the compute server and use the thumper as a backup solution.</li>\n<li>Certainly, it would make sense to get consulting services from collabnet regarding the planning and deployment of this subversion server and to get platinum support for the hardware and solaris operating system from sun.</li>\n<li>Edit (answer to comment #1): For <strong>distributed teams there is the possibility of a master-slave configuration</strong>: <a href="http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/webdav-proxy/" rel="nofollow noreferrer">WebDAV-Proxy</a>. Each local team has a slave server, which replicates the repository. The developers get all checkouts from this slave. The checkins are forwarded transparently from the slave to the master. In this way, the master is always current. The vast majority of traffic is checkouts: Every developer gets every checkin any developer commits. So the checkout traffic should be 99.97%  of the traffic with 3000 developers. If you have a local team with 50 developers, the checkout traffic would be reduced by 98%. The checkins shouldn\'t be a problem: how fast can anybody type new code? Obviously, for a small team you won\'t buy a thumper. You just need a box with enough hard drive space (i.e. if you intend to hold the hole repository 10TB). It can be a raid5 configuration as data loss isn\'t the end of the company. You won\'t need Solaris either. You could put linux on it if the local people would be more comfortable with it. Again: ask a consultant like collabnet if this is really a sound concept. With this many seats it shouldn\'t be a problem to pay for a one time consultation. They can set up the whole thing. Sun delivers the box with solaris pre-installed. You have sun support. So you won\'t need a solaris guru on site, as the configuration shouldn\'t change for the next years. This configuration means that \n\n<ul>\n<li>the slow line from the team to the headquarter won\'t be clogged with redundant checkout data and</li>\n<li>the members of the local team can get their checkouts quickly</li>\n<li>it would dramatically reduce the load at the thumper - this means with that configuration you shouldn\'t have to worry at all whether the thumper is capable of handling the load </li>\n<li>it reduces the bandwidth costs</li>\n</ul></li>\n<li>Edit (after the release of the M3000): A <strong>much more extreme hardware configuration targeted even more towards insane data integrity</strong> would be the combination of a <a href="http://www.sun.com/m3000" rel="nofollow noreferrer">M3000</a> server and a <a href="http://www.sun.com/J4500" rel="nofollow noreferrer">J4500</a> array: \n\n<ul>\n<li>the J4500 Storage Array is practically a thumper, but without the CPU-power and external storage interfaces which enables it to be connected to a server. </li>\n<li>The M3000 Server is a Sparc64 server at a midrange price with high end RAS features. Most data paths and even cpu registers are checksummed, etc. The RAM is not only ECC protected but has the equivalent of the IBM Chipkill feature: It\'s raid on memory: not only single bit errors are detected and corrected, but entire memory chips may fail completely while no data is lost - similar to failing hard drives in raid arrays.</li>\n<li>As the ZFS file system does CPU-based error checksumming on the data before it comes from, or after it goes to the CPU, the quality of the storage controller and cabling of the J4500 is not important. What matters are the bit error prevention and detection capabilities of the M3000 CPU, Memory, memory controller, etc.</li>\n<li>Unfortuntely, the high quality memory sticks sun is using to improve the quality even more are that much expensive that the combination of the four core (eight threads) 4GB Ram M3000 + 48 TB J4500 would be roughly equivalent to the thumper, but if you would like to increase the server memory from 4GB to 8, 16 or 32 GB for in-memory caching purposes, the price goes up steeply. But maybe a 4GB configuration would even be enough if the master-slave configuration for distributed teams is used.</li>\n<li>This hardware combination would be worth a thought if the source code and data integrity of this 3000 developer repository is valued extremely highly by the management. Then it would also make sense to add two or more thumpers as a rotating backup solution (not neccessary to protect against hardware failure, but to protect against administrator mistakes or for off-site backups in case of physical desasters).</li>\n<li>As this would be a Sparc and not a x86 solution, there are certified <a href="http://www.collab.net/downloads/subversion/solaris.html" rel="nofollow noreferrer">Collabnet Subversion binaries</a> for this platform available freely.</li>\n</ul></li>\n<li>One of the advantages of subversion is also the excellent documentation: There is an excellent book from <a href="http://oreilly.com/catalog/9780596510336/" rel="nofollow noreferrer">O\'Reilly</a> (<a href="http://svnbook.red-bean.com/" rel="nofollow noreferrer">Version Control with Subversion</a>) also available for free as a <a href="http://svnbook.red-bean.com/nightly/en/svn-book.pdf" rel="nofollow noreferrer">PDF</a> or <a href="http://svnbook.red-bean.com/nightly/en/index.html" rel="nofollow noreferrer">HTML</a> version.</li>\n<li>To sum it up: With the combination Subversion 1.6 + Solaris 10 + 3-way-raid-1 redundant and checksummed ZFS + thumper + master-slave server replication for local teams + sun support + collabnet/clearvision/orcaware/Karl Vogel consultation + excellent and free subversion manual for all developers you should have a solution which provides \n\n<ul>\n<li><strong>Extremely High Data Safety</strong> (very important for so much source code - you do not want to corrupt your repository, bit errors do happen, hard drives do fail!) You have one master data repository which holds all your versions/revisions really reliably: The main feature of source control systems.</li>\n<li><strong>Maturity</strong> - Subversion has been used by many, many companies and open source projects.</li>\n<li><strong>Scalability</strong> - With the master-slave replication you should not have a load problem on the master server: The load of the checkins are negligible. The checkouts are handled by the slaves.</li>\n<li><strong>No High Latency for local teams behind slow connections</strong> (because of the replication)</li>\n<li><strong>A low price:</strong> subversion is free (no per seat fee), excellent free documentation, over a three year period only 8$ per seat per year hardware and support costs for the master server, cheap linux boxes for slaves, one-time consultancy from collabnet et. al., low bandwidth costs because of master-slave-replication.</li>\n<li><strong>Ease of administration:</strong> Essentially no administration of the master server: The subversion consultant can deploy everything. Sun staff will swap faulty hard drives, etc. Slaves can be linux boxes or whatever administration skills are available at the local sites. Excellent subversion documentation.</li>\n</ul></li>\n</ul>\n'}, {'answer_id': 87006, 'author': 'nav.jdwdw', 'author_id': 10312, 'author_profile': 'https://Stackoverflow.com/users/10312', 'pm_score': 1, 'selected': False, 'text': '<p>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)</p>\n\n<p>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.</p>\n\n<p>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.</p>\n'}, {'answer_id': 110568, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': -1, 'selected': False, 'text': "<p>I'd highly recommend SVN with TortiseSVN client and Visual-SVN add-on for developers using Visual Studio.</p>\n"}, {'answer_id': 110606, 'author': 'MarkR', 'author_id': 13724, 'author_profile': 'https://Stackoverflow.com/users/13724', 'pm_score': 1, 'selected': False, 'text': "<p>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.</p>\n\n<p>Internally some groups deliver releases to other groups to use in their products; this is not managed through a SCM system.</p>\n\n<p>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 &amp; 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.</p>\n"}, {'answer_id': 116279, 'author': 'Darcy Casselman', 'author_id': 5062, 'author_profile': 'https://Stackoverflow.com/users/5062', 'pm_score': 2, 'selected': False, 'text': '<p>Okay, outright disclaimer: I\'m a developer for a company called <a href="http://www.mks.com/" rel="nofollow noreferrer">MKS</a> which makes a version control system for "enterprise" companies as part of a software configuration management platform called <a href="http://www/products/index.jsp?page_id=14726">Integrity</a>.  Blah blah blah, obvious plug.  </p>\n\n<p>So I can\'t honestly answer the question.</p>\n\n<p>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.</p>\n\n<p>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 <em>their</em> managers.  </p>\n\n<p>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.</p>\n'}, {'answer_id': 262080, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 0, 'selected': False, 'text': '<p>Let\'s see the options.</p>\n\n<p>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)</p>\n\n<p>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.</p>\n\n<p>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.</p>\n\n<p>4 - MS Team Foundation It may be a good solution but I never tried and is probably Windows only.</p>\n\n<p>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).</p>\n\n<p>I would NEVER, EVER, ABSOLUTELY No WAY JOSE use Clearcase. PERIOD It is a waste of everybody\'s money and time and sanity. </p>\n\n<p>Steer clear of: CVS / Clearcase / anything older</p>\n'}, {'answer_id': 5772309, 'author': 'Stripes', 'author_id': 431272, 'author_profile': 'https://Stackoverflow.com/users/431272', 'pm_score': 2, 'selected': False, 'text': '<p>Summary: of the systems I\'ve had personal experience with git would handle this the best.</p>\n\n<p>Detail:</p>\n\n<p>I\'ve worked at several large companies with lots of developers.   At a prior job (I would guess around 500 devs) we used (because of the era) RCS and CVS.   Another group also used ClearCase.   The ClearCase group had significant problems, but I never knew if it was due to ClearCase or misuse of whatever the ClearCase methodology should have been, or a poor ClearCase admin staff.</p>\n\n<p>At the company I\'m with now (well in excess of 10000 devs, but I doubt more then 1000 are on what most people would think of as a single project, although they ARE that many on a single <em>product</em>), we have used CVS (for historical reasons), SVN (because it was an easy migration path), SVK (nice at the time, but I wouldn\'t recommend it), Mercurial (sorry, no direct experience), Perforce (ditto), and Git.</p>\n\n<p>Unless you get warped into the past and trapped there I wouldn\'t recommend RCS or CVS.   They had nice points, but compared to more modern version control systems they have nothing to recommend them.</p>\n\n<p>SVN is stable and mature, and branching is way way way faster then CVS (seconds not minutes for a large project).    However merging those branches in is still a little primitive (in simple cases a little shell script can make it pretty easy, but if a branch got updated and had stuff pulled in that was also committed elsewhere it is very hard to manage).   SVN source repos also seem to need more care and feeding then any other open source repos (but less then the commercial ones seem to take).    SVN has a nice simple conceptual model.</p>\n\n<p>However you have "several sites (some behind a very slow link)", SVN works for that, but doesn\'t work all that well for it.  It is not only slower for the people at the "slow site", but while the "slow site" people do some operations everyone else is locked out.      Despite that I would say SVN works well for groups that have fairly good (fast and reliable) access to the central repo.</p>\n\n<p>SVK worked much better for our "slow sites" (and allowed significantly more "detached work").   It also worked much better for complex merges then SVN.   SVK is no longer maintained, otherwise I would recommend it.</p>\n\n<p>Git is relatively young for a huge enterprise to be seriously considering, but that aside…</p>\n\n<p>It does a good job BUT has a fairly steep learning curve.   More so to groups that already use a centralized source control system.   One thing that helps here is to formalize things like "X is the authoritative repo for project Y" and take all your old review processes and such and apply them to that repo (if you use to need a code review from R and a sign off that tests T passed before checking into your old source control system\'s trunk, require the same things before doing a commit to the authoritative repo\'s master branch).</p>\n\n<p>In some ways git actually works <strong>better</strong> for large groups then things like SVN.   You can enforce process by having only a small number of people able to commit to whatever repo you designate as authoritative.   Those people can be responsible for ensuring all the "process" has been followed before they pull changes into the repo.   Git will even keep track of who made the changes vs. who integrated them (something that SVN seems to get wrong a lot of the time).</p>\n\n<p>Git makes it even cheaper then SVN to create branches (you can do it disconnected, and it is less then a second vs. maybe 3 seconds on SVN), but while most people claim that as a huge deal it isn\'t.   The big deal is the merges are very very easy.   Even in cases where you have done things like started a branch, done half the work, had to work on something else for a month, update the source in your branch because other people have changed the base project over the month, then done the second half of the work, got sidetracked, had to come back later found out that there was a 3rd half of the work, more external updates, and so on…     …even after all that the merge figured out what stuff was really new in your branch vs. came in from your updates and keep the amount of stuff that really needs merging to a minimum.</p>\n\n<p>There are a lot of things I dislike about git, but they almost all come down to "some of the tools are sharp and you should be careful".   Things like a lot of the operations that don\'t exist in things like SVN should only be done on commits that only exist in your repository (don\'t edit history others have seen!).   Other source control systems have similar issues, but git has more emphasis on editing history to kept it "clean", so there are more tools and options to tools that you either need to ignore, or know when it is safe vs. a disaster.    On balance I find it superior to other version control systems I\'ve used.</p>\n\n<p>My second hand info about Perforce is "it is kind of better then SVN and kind of not".     My second hand info about Mercurial is "it is more or less like git except in the details, some like it better others like Git more".</p>\n\n<p>Of corse at a company with 1000+ developers I would recommend that you get a support contract for whatever source control system you use.   For git I would look at github:fi.</p>\n'}, {'answer_id': 5773014, 'author': 'julx', 'author_id': 475763, 'author_profile': 'https://Stackoverflow.com/users/475763', 'pm_score': 1, 'selected': False, 'text': '<p>I\'m horrified that most of the people here advocating for DCVS-es here are taken as some kind of fanboys. DCVS-es are rendered as yet another buzzword just like say cloud computing, social media, etc.</p>\n\n<p>Some people here are advocating for usage of SVN along with some specific hardware setup, specific disk storage that is supposed (or even is capable of) bringing reliability to the table. Now isn\'t that just defeating one of the two main purposes of an SCM - namely ensuring data integrity?</p>\n\n<p>You don\'t have sufficient information on the data storage level to ensure integrity of the whole source base across all the past revisions. What if you wish to migrate the data onto another machine? What if you want to migrate it gradually without stopping all development until it\'s done? What if there is a security issue and somebody messes up with your main copy? How do you find the last valid one? Storage integrity gets you only that far, and will give you no means to solve any of those issues. It\'s exactly because it operates on an inappropriate level of abstraction. Is not the storage you\'re concerned with. It\'s your code base.</p>\n\n<p>Another issue. Some people can\'t believe it\'s actually possible for 3000+ people to operate within the same project. They say "go and bake your own scm", which I imagine is another way of phrasing "yea... right... 3000+ devs... good luck with that". At the same time there are projects that involve many more people. Take just about anything from engineering to law.  But somehow when it comes to software development it\'s impossible, it can\'t be. The thought (I imagine) goes something like this: What? 3000+ people touching the same file? Now, that can\'t be. And, yea it\'s correct. It can\'t be. The question is why would you ever let 3000+ people touch the same file? Where in nature would you ever find such situation? Do 3000+ lawyers send each other a single document until they eventually agree on everything? People don\'t work like that. It\'s never possible to work in reality like that. Yet a centralized CVS theoretically makes it possible. Even worse it forces people to actually coordinate their work with individuals they don\'t even know. In such situation it\'s not even an issue of having smart people on board, although out of thousands of people I imagine it\'s quite hard to guarantee that each and every one of them is not an idiot. It\'s simply about making common stupid mistakes. Everybody commits errors (literally). Why would you suddenly like to inform the entire company about it? </p>\n\n<p>Now some may say - but you don\'t have to give commit access to everybody. Well - that\'s cheating. It\'s exactly a hopeless attempt to build a distributed work flow in a centralized environment. Suddenly you have a two level tree - people with commit access send the work by all those, who don\'t. Well if you went that far, why not just agree on the inevitable - that there isn\'t and never will be just a single common version of the whole source base. That people need to work within their detached environments that can be than easily merged together.</p>\n\n<p>There are many DCVS\'es these days. Only Git has this approach of tracking content and not individual files, which in this case might not be an optimal choice (however it very much depends on the organization of the project). There is also Mercurial, there is Bazaar. So the two properties don\'t depend on each other.</p>\n\n<p>I don\'t really want to recommend any specific DCVS out there, I don\'t feel that competent. However in a situation where most of the recommended solutions are not distributed, don\'t ensure data integrity, are actually worse than not having any CVS at all, I felt like I need to write something. The question really should be which DCVS is best fit for doing the job.</p>\n'}]
['https://Stackoverflow.com/questions/65458', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/9362/']