I remember migrating some codebase from CVS to SVN ... and this was sometime after CVS was adopted instead of "at the end of the day, every dev will copy his change into a floppy disk and give it to the Tech Lead for merging".
This was during the 90s in a software development company in Mexico. Good times!
> This was during the 90s in a software development company in Mexico.
Version 1.0 of svn was released around 2004. According to wikipedia the project was started around 2000.
(Sidenote: there seems to be cognitive dissonance that svn was released much earlier than git ... but svn was released in 2004, and git in late 2005. There's a less than two years gap in between, yet so many projects had been "stuck" with svn...)
IIRC, svn was marketed as "CVS done right" [1], which meant devs who were exploring alternatives to CVS didn't have to worry about svn's learning curve.
So, I think inertia may have been a huge part of why adoption of svn was so good compared to git that has a steep learning curve, even today.
Source control is an inherently distributed system. Each developer has their own copy of the code that are distributed across many computers, and they need to communicate between each other. That's exactly what the primary function of the software is.
That's just as true with SVN, (for the local in-progress working copies) but with a single, centralized history. Which is how most devs use git anyway (essentially emulating a centralized versioning system workflow), and in this case the distributed nature of git allowing many alternative histories is unnecessary in the best case, and massively gets in the way in the worst case (because for most projects a single history is actually a feature).
(In a very real sense, the server from Subversion does the same job of the optional server from Operational Transform: it is acting as a sequencer. The next thing we could do is replace that with proof-of-work, and then we could have a fully decentralized system with the properties of Subversion ;P.)
Git is true mesh source control system. You only need one .git folder to survive and you haven't lost anything. My memory is fuzzy but with svn if you lost the central repository you were in a world of hurt.
This is what git does right. What git lacks for me is smoothness in interaction with the user. To use git well you must think like git. Which is kinda annoying when I prefer my tools to think like me.
When I moved from svn to mercurial it was absolutely painless. On my next company git was terrible experience. I am sure that git tools and flexibility are amazing for linux kernel and other projects of the scale. But probably are overkill for smaller stuff when a more friendlier user flow will be nice.
My memory is that SVN was very popular long before 1.0, I feel like by 2002 it was "beating" CVS for new projects among hobbyists. It was the exemplar for VC in my SE course at university in early 2003.
As I remember, the initial versions of Git would have been a chore to use; the intention was for it to be only the "plumbing", with a more friendly front-end layered on top. So it took a good few years to change that, and for it to catch on.
This was during the 90s in a software development company in Mexico. Good times!