What do you lose by moving to distributed version control from Subversion? When is using Subversion the right choice?

This is a follow-up post 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 , 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 equivalentis 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 mistaketo 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 we use 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 identifying commits, tags, and revisions by hexadecimal strings of 8 to 24 characters.



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.
Full Post