There are certainly good things about DVCSes like Git or Mercurial that you miss when using SVN.
On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.
Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.
A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.
The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.
I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.
On the other hand, every project I've ever worked on that has used Git still had some sort of centralised repository that was considered authoritative for controlled release purposes. The smart projects had a local server for this that everyone pushed to. The over-enthusiastic used GitHub, and in at least one case then found themselves unable to deploy when their systems were all up but GitHub was down.
Within that master repository, having a single linear history so you can identify exactly which code you've got in any given release with just a revision number is often helpful. In Git you simply don't have this, so you have to manually tag everything you might ever want to reproduce, which is basically everything on your master server, which requires extra hassle and clutters your log.
A separate but very practical issue is that SVN has worked fine on Windows for years. Git's support for Windows is getting better, but still far from ideal even today.
The sheer complexity of Git, up to and including data loss bugs because even Git's own scripts didn't track everything properly, is another recurring concern.
I've seen more than one very experienced developer, well aware of the pros and cons of different tools, argue for using SVN on a new project for these reasons alone.