On the one hand, SVN integration (with IDE, frameworks, wikis, …) is very mature, as well as its GUIs and code browsers (even though DVCS like Git and Mercurial progress every day).
On the other hand, introducing a DVCS in an Enterprise environment is still not a trivial task:
- Some requirements are not easily met (in terms of security and access control, administration and restriction of access)
- The DVCS paradigm is more complex to understand, with lots of pros and cons.
- You really need to leverage its many workflows instead of relying on the SVN centralized one.
- The transition from CVCS to DVCS is difficult
Just to be clear, using a DVCS can be a very valid choice:
- for a new project, where the developers are not tied with legacy tools or processes
- especially when the developers are not geographically located in the same place (often the case with open-source development, which is why DVCS are mainly used there).
StackOverflow (not an open source project) is using Mercurial (see HgInit, written by Joel Spolsky).
They migrated from SVN to a DVCS:
- in part because their developers are now all over the world(!)
-
and also because the merge facilities of a DVCS are much more advanced than in SVN.
(which they need to maintain many parallel slightly different versions of their code base, between SO sites, StackExchange sites V1 and V2, Area 51, …)
See “differences between DVCS and CVCS“, or “What are the benefits of Mercurial or git over svn for branching/merging?“. -
For a corporate environment (where I am), any transition of any kind is not trivial, because it need to be:
- funded (money, even if the tools are free)
- supported (that means having the right people with the right competences)
- integrated (with existing legacy tools, GUIs, IDEs like a Visual Studio or many others, …)
- administrated (in term of common servers, even for a DVCS)
- documented (especially for users coming with a CVCS like SVN background)
So DVCS can also be very useful in a corporate environment:
(See “Corporate adoption rate of Git?” or “Git-Based Source Control in the Enterprise: Suggested Tools and Practices?“.)
It is (even for new projects) simply not as easily put in place than in a smaller structure or in open-source environments.