Are there any actual business cases that have made any company move from a DVCS to a CVCS (regardless of whether they were on a CVCS originally)?.
Other than having a closed mind and rejecting the paradigm shift altogether (for the particular case of companies coming from a CVCS) I cannot think of any cause for this happening.
Double chocolate cookie for anyone with empiric evidence.
I do Mercurial consulting and my experience is that big companies spend a lot of time up-front to investigate the pros and cons of DVCS. So when they finally take the jump, they've already been using DVCS for one or two pilot projects and so they're pretty certain that it will work for the rest of the group.
However, I do know of one example where Mercurial was tested in production but then abandoned. It was a client that do hardware design and that involves a huge number of binary files that don't compress or merge very well. We're talking about 10,000+ files, each maybe 10 MB in size. So a checkout alone is more than 100 GB in size.
Before contacting us, the client spend a lot of effort on writing an extension for Mercurial that would externalize the storage of these files. The idea was that files would be downloaded on demand when you do a checkout — not when you do a hg clone. That was the history of each file would be stored on a central storage server and the clients would only download what they really need. Very much like Subversion, but with the advantages of DVCS for all the other project files. (Mercurial now ships with a largefiles extension that implements this idea.)
However, despite their efforts, they were not able to make their extension run efficiently and the hardware team eventually went away from Mercurial and started evaluating more traditional systmes such as Perforce. I don't know all the details and I feel that we should have been able to make it work, especially by using the now-standard largefiles extension. Granted, the extension will not be perfect for 10,000 files as it is now (the per-file overhead is too big), but that is something that can be solved one problem at a time by batching queries and stream-lining things.
So my advice is:
Make sure to do extensive testing before deploying a DVCS. Find a small group of developers that think DVCS is cool and let them run a project or two.
Contact someone who knows what works well and what works less well. Above, we were only called in pretty late in the process and at that point the client had committed themselves to a non-optimal choices. There is a number of support options for Mercurial and I will encourage you to use them.
The two aren't exclusive alternatives.
CVCS tools provides strong authorization features.
Some have their own built-in authentication mechanism (SVN with svnserve, RTC and its user registry, Perforce and its P4Admin): they can have their own internal user database, dedicated for their tools.
DVCS tools don't. See "Can we finally move to DVCS in Corporate Software?".
No built-in authentication and authorization mechanism.
DVCS: No authentication:
While CVCS can interface themselves with external authentication sources (like an LDAP), DVCS have no choice but to interface themselves to external authentication sources, using only external processes (openssh, httpd, ... since they own internal lightweight server has no authentication contrary to a SVN svnserve).
DVCS: No authorization:
If you have access to the repo path (through file, ssh or http), then you have all privileges on it (read, write, delete, ... on any branch).
If you need a finer-grained access control, you need to add an extra layer to the tool (RhodeCode for Mercurial or Gitolite for Git).
Those constraints mean that a DVCS has usually different use cases than a CVCS within a large company.
For instance, I have put in place both, with DVCS used to allow third-party enterprises to collaborate on a restricted shared code-base with the company.
Considering a DVCS allows for cloning a all repo with its complete history, that meant we had to come up with an import-export mechanism allowing us to export and publish in the DVCS only certain part of the CVCS (large) repo, in order for said third-parties to access only what they need to work on.
