[mahyarm]

Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.

Younger devs who do have experience with this stuck in their ways behaviors and it can be frustrating and they try to side step it by not engaging the older devs.

[Silhouette]

Other 'sticks with what they know to a detriment' are devs that stick with SCMs such as svn or cvs or even rcs when things like git or mercurial are out there.

Don't mistake not buying the hype for sticking with something just because you know it. While there aren't a lot of reasons to favour RCS or CVS when Subversion exists, there are sensible reasons you might favour SVN over a DVCS for some projects.

[mahyarm]

It's been 10 years since git has been released, and in my personal case when this happened, there wasn't any good reason other than 'it's what I know'. The company started with SVN when git had been around for a while.

It's slowed down the company globally, prevents us from using various tools that don't have svn compatibility (like android's repo, gerrit or git's client side pre-commit hooks) and overall just been a relative pain the ass compared to git.

The very small edge cases that svn might be better at now did not apply to us. Notice I didn't say perforce, or google's custom solution in my example.

[Silhouette]

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.