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

Question

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 Mercurial 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?

Truckle

The choice of any technology should be influenced by the other technologies that you want to integrate. So, if you've got a ton of other tools that integrate with Subversion but not Mercurial, then go with Subversion. – Sharynshashlik

@Nathan D. Ryan: But that should not be the only criteria. If it were, no new technology would ever gain a foothold because the network effects of the old technology are too strong to overcome. – Gudren

@Omnifarious: Agreed. I didn't mean to imply that should be the only criteria, but from a practical perspective it should be a consideration. Personally, I use Subversion for local repositories of personal projects, and have switched over to git for everything else. The extra layer of indirection involved in distributed version control makes it superior for collaboration, IMO. – Sharynshashlik

Answer 1

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.

Edna

Answer 2

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.

Gudren

Yep, that's the only reason I use SVN at work (instead of Monotone, that I always use when I have a choice)… and using SVN is something I regret it at ever single merge I have to do, expecially when I'm forced to break a working version before commit just because it was not against head. – Built

You're the only one on this page to mention the PRIMARY things that svn and Perforce can do which hg and git cannot. THESE are the actual considerations that anyone who intelligently chooses Central VCS would have to make. There is no other defensible reason. – Speedway

Answer 3

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

Recently

TortoiseHg has recently released version 2.0.X and rolled in several improvements over v1.X.X and several new features. If you claim Tortoise as a reason not to use Hg, you should check it out. – Verdellverderer

Answer 4

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

Lessielessing

The problem with this approach is that then you make gaining those advantages very difficult in the future. You self-limit at the very beginning. – Gudren