When and why will you choose centralised (SVN) over distributed (Git, Mercurial)

Recently in my new job, my department (we are mainly building stocks and horse racing websites and we only work on the website in office.) is considering over to use SVN or Mercurial. Our project manager says he favor SVN (didn't give us his reasons) but give us a choice to choose Mercuri开发者_Python百科al too and ask us for our opinions (final decision still lies with him)

Given that most articles online are about explaining why choose Mercurial over SVN (or something similar). I would like to ask the opposite.

So when and why will you choose SVN over Mercurial in a new project despite the many advantages of Mercurial/Git over SVN?

---

When I'm forced to by the popular opinion of co-workers or management by fiat. That is the most likely scenario.

There are some specific situations in which I would choose Subversion or Perforce over Mercurial. Those have to do with very specific features. For example, the ability to treat random subdirectories as repositories in their own right can be useful in some situations. Perforce's ability to re-arrange directory structure on checkout can also be useful. Perforce also does a superb job of handling large binary objects as are used in game development and other kinds of media work, and neither Mercurial nor Git are currently particularly good at those things.

But in general, there is no other reason I would ever choose a non-distributed revision control system for myself. I find them immensely limiting and constraining. I've been disappointed with them ever since I learned what version control was. There is nothing from a pure workflow standpoint that can be accomplished with a centralized revision control system that cannot be accomplished with a distributed one.

---

Subversion is a very good centralized version control system. It is mature, and well-supported by other tools like Trac. Its "one-version-per-snapshot" is outstanding, and a "branch" is merely a "light copy". Really, in the context of legacy version control with more "brittle" semantics (like version-numbers-per-file and their own idiosyncrasies), Subversion is outstanding. (I've used it for years.)

That said, I'm moving to Mercurial. (I'd consider Git, but Mercurial is far more mature on Windows at present.) Tortoise-Hg is not nearly as mature as is Tortoise-SVN. However, both Mercurial and Git are BUILT TO MERGE. And, that's the fundamental problem for version control systems.

With Mercurial, every repository has everything. Merges are simple. A repository is itself a "sandbox", so you don't need to have the "clairvoyance" of "Trunk" and "branches", and do other pre-branch planning. In short, distributed repositories is how teams of developers work, even if the developers are centralized in a command-structure (rolling to a "final approved Trunk" branch).

Summary: Subversion is a great model, but very centralized. It is mature, with mature tools, and mature integration with other tools (like Trac). Mercurial (and Git) are better models, but provide the same "single-version-per-repository-snapshot" as Subversion. The tools (like Tortoise-Hg) are less mature (integration with Trac is more work), and you'll think slightly differently when working with Mercurial (e.g., distributed repositories that are synchronized), which provides some advantages, but you should really think about the problem differently (than you did with Subversion).

I use both daily. They are both awesome. When we get the Mercurial integration with Trac in a more mature manner, I'd move to Mercurial completely. (The less-mature Tortoise-Hg is not as good as Tortoise-Svn, but I can live with it.)

The full migration to Mercurial-only may take a while (like over a year or two, as Trac provides better native Mercurial integration). The import/export between Mercurial and Subversion is not terrible. We use both in our existing code base: Central "trunk" is Subversion, and local changes are in Mercurial, with final check-in back to Subversion. It works.

If you couple to other tools, just check for its interface with Subversion and Mercurial. If all things are equal, go Mercurial. Otherwise, you can't go wrong with Subversion (we use Subversion specifically because of support by Trac), and it's fine to use Mercurial on top of that (we do).

Finally, in the context of how you framed your question:

So when and why will you choose SVN over Mercurial in a new project despite the many advantages of Mercurial/Git over SVN?

I'd choose Svn over Mercurial because:

1. Integration with other tools (like Trac) is more mature, and we use those other tools;
2. Utility interface (like Tortoise-Svn) is significantly more mature than Mercurial front-ends (like Tortoise-Hg);
3. Subversion is conceptually a very simple model (e.g., single-version-snapshot), and the centralized repository is how people historically think about version control (different thinking is required for the distributed Git/Mercurial model)
4. We have a solid process that plans "trunk" and "branches", and do not require significant tool support to help with those painful merges-across-branches.

---

One word: TortoiseSVN. To me, TortoiseSVN is standard of all GUI clients for any VCS. Despite SVN's shortcomings in fron of DVCS, TortoiseSVN makes using SVN a breeze. TortoiseGit is pretty good and models TortoiseSVN, but TortoiseHg is not so great.

Another reason is awesome sysadmin support. The tools are well developed and mature when it comes to SVN. Both Git and Hg are yet to catch up.

You can also look at my answer here: which version control is best suited for me?

Also this which is a very similar question: https://stackoverflow.com/questions/2693045/mercurial-vs-subversion

---

When the advantages of Mercurial are not advantages you will use or apply to your situation.