SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.
It is its own footgun as well, but with git you can git init any directory you want and have a repo. Other than the learning curve of the not particularly well tuned CLI (and there are all sorts of graphical clients today and alternative CLI clients), it's very low barrier to entry to get something/anything in source control.
It's not just "larping as leet hackerz", there are real benefits to git over SVN. There are fewer barriers to entry for small teams and hobby devs, especially in a world with GitHub/GitLab/Sourcehut/and more, but also in the world where maybe a git repo never syncs with any other single machine or is hosted on the barest feature set SAMBA folder or is only ever using email-based PR flows.
git could be easier to teach. git could have a better out of the box CLI. That doesn't mean "git is overkill" especially from the point of view of "needing a whole central server setup just to store multiple versions of a file is overkill". Git is perhaps "underkill", it does the bare minimum as best it can in whatever environment you give it. It's intentionally dumb and stupid (hence its name, to be fair) and it's learning curve is as much because it is "too dumb" than because it "isn't intuitive". I've seen some "intuitive" UIs built on top of it. Another comment here remarked "git isn't a source control system, it's a low level toolkit for building your own" and that's not far from the truth and definitely not far from git's origins (and its name). That's a sort of "underkill". ("One day we'll finally build the right, intuitive high level API." That's basically how git was designed. You don't have to just take my word on that, you can search the old mailing lists for all sorts of interesting discussions and debates on "porcelain" options.)
Many years ago, SVN worked fine for me for single-user projects. I just made my own desktop be the server. But I wasn't publishing my code back then (it's not as if I would have have any effective way to tell people about it anyway). Now I have no idea how the equivalent of "pushing to origin" would have worked.
You can even do it on shared directory for a small team even it's not recommended if there is a lot of concurrent users.
No, but seriously, I wrote https://andrew-quinn.me/reposurgeon for a reason. While I actually see some big benefits to SVN over git for areas with large binary assets like game development, the tool is just so ancient these days that it's just easier for me to convert SVN repos to git repos and then use those to figure out what I actually need to do. It feels a lot like working with Laplace transforms, translating and un-translating between two not quite equal ways of measuring reality.
That's not even considering that the kinds of companies still using SVN in 2025 tend to have a lot of code to wade through. Serious selection effects in play there -- mostly for good, to be clear.
Svn can branch and merge - maybe bit more clunky but still works