Ovid

From a so-called objective standpoint, there aren't any compelling reasons. However, there are a couple of things that could be considered compelling depending on your situation:

• Your team have mastered and are using centralized VC and are too busy to learn something new. This is easily argued (both ways), as it is just a rephrasing of the question in reverse: What compelling reasons are there to use decentralized VC?
• Your change process at your workplace is prohibitive, so that while you may want to switch, the administrative and bureaucratic costs associated with the change make it more trouble than benefit.
• Your in-house toolchain is tightly bound to the centralized VC solution you are using, and very mature. Migrating and adapting these tools to DVCS could cost more than you are willing to spend in terms of effort.

In theory DVCS is a complete superset of VCS, so you should never choose the latter.

In practice people still use the centralized systems because of familiarity, or because of support from their favorite IDE.

Look broader. Are there any compelling reasons to choose centralized versus decentralized software development? Absolutely and it happens all the time.

Consider Perl. Perl development has migrated to git, but Perl is still a centralized process. There is one official Perl development branch. It's the only one that will be released to the world as "Perl".

A centralized VCS enforces centralized development more rigidly than a decentralized one does. Core commits and branching is limited to a pre-approved list of developers and developing in a VCS outside a central system is tricky. (Tricky, but possible.)

I think using a centralized VCS versus a decentralized one is really a question of the trade-off between control and agility. It seems that projects that adopt DVCS are seeking agility within the tools and are willing to address control through culture and communication outside the VCS.

First, a bit of context. I tend to use my VCS as a distribution system. I install a lot of my code onto various computers by checking it out from the VCS. This makes it easy to keep up to date by simply pulling the latest version.

This necessitates a central repo, regardless of which VCS is in use. With a DVCS, I have found that sometimes I forget to push commits to the central repo. Then, sometime later, I have to track down the local repo with stray commits. With a centralized system, it's not possible: every commit goes to the central repo every time.

Admittedly, developer forgetfulness is probably not the most compelling reason to use a certain piece of software, but it's something.

Right. The problem is that people confuse centralized development with centralized tools. You can do centralized development with a distributed toolset, but not the other way around.

Before Perl moved to git I had to prepare my patches against it with a diff -ru between an rsync copy of perl and a directory with my local changes. With Git I got access to version control for the first time, so did a lot of other people.

Choosing a centralized system for your centralized development model means leaving other people out in the cold without any version control at all. That's harmful to any project that accepts patches.

Locking? In Subversion I can enforce locking on certain files using props, which can help to avoid unpleasant conflicts on binary files. We used to work on website designs stored in PNG files. When you have a conflict on such file, one of the committers has to redo his work by hand. The locking was too much fuss so that we finally decided to work without it, but I can imagine similar scenario where the locking would be a very nice feature to have.

Sorry, I know it's a year old, but that last comment was just so silly that I had to say something.

Locking files or branches is not a feature of centralization. You can enforce such restrictions on a given repository without being "unique", and there exist such tools for Git et al. While everyone still has complete dominion over their own fork of the code and are free to obey or disobey these rule as they choose, the maintainer retains the right to reject commits that break them.

However, none of that should even be relevant to your issue with PNG files. Conflict resolution is, again, completely independent of distribution. Both SVN and Git will retain all preexisting copies of a conflicted file, so if you merely intended to choose one version in its entirety over the other, there's no need to hand-edit. The fact that the VCS doesn't try to read your mind by committing some arbitrary combination of the two files should be considered a feature.