lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.
lol, I don't think that's the reason. At the only place I worked that used SVN the real reason was that the old guys didn't want to learn something new.
That was only ~6 years of commit history too. I could imagine 30 years is a whole extra logistical challenge. Not to mention making sure the whole developer base is aware of the change, prepared for it and willing to either update documentation where it refers to revision numbers or write some instructions on how to find a new commit reference from an old revision number.
The tag model is also different between svn and git.
It's not out of ignorance that the switch can be difficult, we've had some projects on git for years and we're comfortable with it.
Just because you've switched easily from svn to git doesn't mean everyone has the same experience.
(And personally, I hate git. I've used it professionally, and while it works, it's very difficult to use compared to svn or p4. Between it's utterly incomprehensible made-up terminology and horrid syntax, and hashes for commit numbers instead of just an incrementing integer, it's quite a bit less useful than svn was for us. But it's being forced on us, unfortunately.)
Of course if you're young, it's no big deal since you haven't been using SVN for decades, and what's the big deal with learning something new? But when you've been around the block a few times, sometimes there's needs to be a better reason than the new and shiny.
At this point I'd go as far as saying that git is objectively superior to SVN because it does everything SVN can and then more. One caveat being potentially very large repositories and especially repositories containing sub-repositories, git was terrible at that and while it's improved over the past decade it's still a bit messy. Unfortunately in my experience these types of repositories are fairly common in proprietary codebase where people often don't hesitate to commit big binary files alongside the source code.
Still, I'd say that as a rule of thumb if a codebase is still in active use it's probably worth taking a week or so to migrate it to Git unless there's a very good reason not to.
I went through periods where I had to use CVS, then SVN, and then git. The transition period between each one was a little problematic since I had to constantly refer to the documentation in order to learn the new source control commands, but, in my opinion, one should be capable of learning new technologies.
Real men use cvs.
(I kid.)