As a "younger" programmer it always shocks me how things like git were only created in 2005. It feels so ubiquitous and the way it functions has the "feeling" of something created in the 80s or 90s to me.
Svn gets a lot of hate for things it doesn't deserve, even this article talks about "checking out" and the difficulty of branching, but that doesn't track with subversion.
Branching in subversion was just as easy as in git, it had shallow branches. You could branch largely without overhead, although unlike git it was a server-side operation. ( Imagine it like git branch with auto-push to remote).
Most software also automatically checked out files as you modified them, and it was a local oepration, there wasn't any locking or contention on that. It was the older CVS/sourcesafe style version system that those.
I still maintain that most workplaces with less than, say, 10 devs, would be better off with subversion rather than git, if not for the fact that most the world now works on git.
Subversion solves problems with less mental overhead than git, but it's not worth doing anything non-standard, because everyone now knows git and has learned to put up with the worse developer user experience, to the point where people will argue that git doesn't have bad UX, because they've internalised the pain.
Before subversion there was CVS and Visual Source Safe. These are much older. These solved a problem of source control, but were based on the concept of locking and modifying files.
You'd "checkout" a file, which would lock the file for modification of all other users. It was a bit like using a global locking file repository but with a change history.
It was as painful as you might imagine. You'd need to know how to fix the issue where someone would go on holiday having checked out a critical file: https://support.microsoft.com/en-us/topic/5d5fa596-eb9c-d2b5...
Or more routinely, you'd get someone angrily asking who had such-and-such file checked out.
It was about merge and conflict resolution like SVN or Git.
VSS was oriented around locking. And also broke all the time. Oh, and also lost data... And oh, it was also the expensive one used by everybody that kept saying "you get what you pay".
And even if I was using it wrong or SVN improved merging later the fact was that common practice at the time was to just commit everything to the main branch, which is a worse (IMO) workflow than the feature-branch workflow common in git.
But you're right, SVN was largely fine and it was better than what preceded it and better than many of its peers.
Edit: Forgot to mention - one of the biggest benefits to git, at least early on, was the ability to use it locally with no server. Prior to git all my personal projects did not use version control because setting up VC was painful. Once git came around it was trivial to use version control for everything.
And honestly, it was always a pain in the ass setting up "the server". Unlike with git you needed a server / service running 24/7 upon which to check your code into. Which was always a pain in the ass at home... needed to keep some stupid subversion service running somewhere. And you'd have to go back into that service and remember how to create new projects every time you got a wild hair up your ass and wanted to create a new thing.
Git you just do "git init" and boom, you have a whole complete version control system all to yourself with no external dependency whatsoever.
That being said, TortiseSVN was the best GUI for version control ever.
The github's desktop app in particular is a mess, because it does not try to be a UI, it's simply a frontend for the CLI , having buttons for the CLI operations basically, and it does everything worse than CLI.
In hindsight, it's hard for me to take seriously a programmer who can't spend some time to learn git, it isn't hard.
The assumptions of SVN makes it feel like a dinosaur now.