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.

  • 1
    Why would these gigantic binary files need to be in version control? Datafiles for a needed tool which do not lend themselves well to versioning? – user1249 Apr 22 '12 at 10:03
  • Some times binary files are not necessarily generated from compiling the code. In my company, the projects require a good ammount of binary files (navigation) which are sometimes changed. Also, in a sense, our VCS is being abused by versioning compiled binary files too that probably (need to investigate) not even the integrators use – dukeofgaming Apr 22 '12 at 19:34
  • @MartinGeisler Would you say largefiles is not ready for production?. Could this problem be partially solved by using subrepos?. Personally I'd just solve this by having the standard procedure for cloning (first checkout) be: clone from a peer, pull from the blessed repo – dukeofgaming Apr 22 '12 at 19:37
  • 1
    @ThorbjørnRavnAndersen: It was my understanding that these binary files were genuine "source" files used for chip design. It was not the usual problem where people add a ton of .jar files to version control because they don't use a proper artifact repository. Maybe one could have restructured the workflow so that they could use an artifact repository — but I was only brought in quite late in the process. – Martin Geisler Apr 23 '12 at 8:12
  • 1
    @AndrewFinnell: Yes, it's the usual story with files that cannot delta-compress well: the history becomes huge and a clone will take ages. You're right that Git can make a clone of only the most recent history, but it's a cripled clone: git-clone(1) says "A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it)". My client wanted a functional clone that they could use for new development. – Martin Geisler Apr 23 '12 at 8:22

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.

  • Doesn't RhodeCode with Mercurial pretty much solve the authentication problem? – pdr Apr 22 '12 at 19:31
  • I was just going to comment this, RhodeCode (rhodecode.org) will be part of the solution/migration/plan I'm proposing – dukeofgaming Apr 22 '12 at 19:40
  • @pdr: my point is: DVCS alone has no authentication (and no authorization). DVCS + an extra layer has (RhodeCode for Mercurial or Gitolite for Git) – VonC Apr 22 '12 at 19:53
  • True, however it is not that hard to achieve transparently (even without something like RhodeCode/Gitolite) blog.bleathem.ca/2010/04/… – dukeofgaming Apr 22 '12 at 20:04
  • @dukeofgaming you achieved authentication. This is not authorization ("process of asking what you want to do and deciding if you're allowed to do it or not"). – VonC Apr 22 '12 at 20:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.