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.