This is a follow-up post with a few counterpoints to the last post about distributed version control. There are a few things that I can see that Subversion does better than either GIT or Mercurial. In the interest of fairness, I will point them out here:
1. It appears that Subversion, given adequate server hardware, and adequate local area network bandwidth, may be a better solution for teams who need to do checkouts more than 2 gigabytes in size, especially if you simply must check in binaries and version control them. Your mileage may vary, in your situation, you may find that the point of inflection is 750 megabytes. A common example of this is video-game development, where assets easily hit 10-20 gigabytes, and are commonly versioned with Subversion.
2. Subversion has support for partial and sparse checkouts, something that you don't get with distributed version controls systems, and all the attempts to add sparse checkouts to DVCS have been so flawed that I would not use them. The nearest relevant and useful DVCS equivalent is submodules. Most users who need to do partial checkouts in subversion will find that they want to investigate using submodules in a DVCS. If submodules do not meet your needs, then maybe CVCS is best for your team. If you need different users to have different subsets of the repo, using scatter/gather workflows, or otherwise do sparse checkouts (svn co http://server/trunk/path/to/sub/module3 rather than being forced in Git or mercurial to do a clone which is equivalent roughly to svn co http://server/trunk/ ) you may find Subversion meets your needs better. It is a common rookie mistake to conflate DVCS repo scope with CVCS repo scope. DVCS repos are typically simpler and smaller intentionally, rather than the subversion "this server is your whole code-universe" monster-mega-repo strategy that Subversion limits you to.
3. Subversion has global version commit numbering, that is your ONE and only Subversion server has a commit counter, and since this global asset is shared among everybody, you can never have a "commit #3" on one computer be anything other than "commit #3" on anyone else's computers. On Git and Mercurial the system generates globally unique hash tags instead to identify commits, and the commit numbers, if available, should generally just be ignored as they are different for each user. For some workflows you might find this global commit numbering system suits you better than referring to the hex strings of 8 to 24 characters that identify your commits, which have no ordering.
If I've missed anything, I'll add it in an update. Anyways, those are the three golden reasons that I know of that some teams will want to evaluate DVCS, and then stick right where they are with Subversion, which by the way, does seem to me to be the best open-source CVCS out there right now. I only wish there was a better GUI than Tortoise, and that they'd do a little work to make command line merging less stupid.
Update: Someone was confused about why you would want users to "generate" hash keys. This means I didn't explain it properly. The version control system generates hash keys, and "hashing" means feeding the input of your changeset through a cryptographic hashing function. The possibility of a hash collision is so low, that you will never encounter one. Git and Mercurial both use them, and I have never heard of a hash collision, ever. My only reason for mentioning it is that in a distributed system there is no single incrementing counter available to give you unique incrementing numbers. Not a big deal, but something to know before you leap. More info here.
1. It appears that Subversion, given adequate server hardware, and adequate local area network bandwidth, may be a better solution for teams who need to do checkouts more than 2 gigabytes in size, especially if you simply must check in binaries and version control them. Your mileage may vary, in your situation, you may find that the point of inflection is 750 megabytes. A common example of this is video-game development, where assets easily hit 10-20 gigabytes, and are commonly versioned with Subversion.
2. Subversion has support for partial and sparse checkouts, something that you don't get with distributed version controls systems, and all the attempts to add sparse checkouts to DVCS have been so flawed that I would not use them. The nearest relevant and useful DVCS equivalent is submodules. Most users who need to do partial checkouts in subversion will find that they want to investigate using submodules in a DVCS. If submodules do not meet your needs, then maybe CVCS is best for your team. If you need different users to have different subsets of the repo, using scatter/gather workflows, or otherwise do sparse checkouts (svn co http://server/trunk/path/to/sub/module3 rather than being forced in Git or mercurial to do a clone which is equivalent roughly to svn co http://server/trunk/ ) you may find Subversion meets your needs better. It is a common rookie mistake to conflate DVCS repo scope with CVCS repo scope. DVCS repos are typically simpler and smaller intentionally, rather than the subversion "this server is your whole code-universe" monster-mega-repo strategy that Subversion limits you to.
3. Subversion has global version commit numbering, that is your ONE and only Subversion server has a commit counter, and since this global asset is shared among everybody, you can never have a "commit #3" on one computer be anything other than "commit #3" on anyone else's computers. On Git and Mercurial the system generates globally unique hash tags instead to identify commits, and the commit numbers, if available, should generally just be ignored as they are different for each user. For some workflows you might find this global commit numbering system suits you better than referring to the hex strings of 8 to 24 characters that identify your commits, which have no ordering.
If I've missed anything, I'll add it in an update. Anyways, those are the three golden reasons that I know of that some teams will want to evaluate DVCS, and then stick right where they are with Subversion, which by the way, does seem to me to be the best open-source CVCS out there right now. I only wish there was a better GUI than Tortoise, and that they'd do a little work to make command line merging less stupid.
Update: Someone was confused about why you would want users to "generate" hash keys. This means I didn't explain it properly. The version control system generates hash keys, and "hashing" means feeding the input of your changeset through a cryptographic hashing function. The possibility of a hash collision is so low, that you will never encounter one. Git and Mercurial both use them, and I have never heard of a hash collision, ever. My only reason for mentioning it is that in a distributed system there is no single incrementing counter available to give you unique incrementing numbers. Not a big deal, but something to know before you leap. More info here.