Subversion (svn) was absolutely fine before git. Before that, there was CVS but that really was painful.
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.
Branching in Subversion was fine, but merging was quite painful (at least at the time I was using it, around 2008ish). From my recollection, SVN didn't try to figure out the base commit for a merge - you had to do that manually. I remember having a document keeping track of when I branched so that I could merge in commits later.
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.
Subversion was great up until your working directory somehow got corrupted. Then you'd be in some kind of personal hell cleaning it up.
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.
Subversion didn’t get working merge support until years after git. Like CVS it basically required trunk-based development. Feature branches were not supported. You needed a separate checkout for any work in progress. You could not checkpoint your work with a commit before updating to the latest head. Every update is a forced rebase. It sucked.
CVS was absolutely not oriented around locking files.
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".
One thing that Git and the other DVCS's massively improved over Subversion is that commits are local, and you only need to talk to a remote endpoint when you push/pull. In Subversion, every commit would require uploading changes to the repository server, which encouraged larger commits (to amortize the overhead).
Yeah, this was huge at the time. Laptops were good but Wifi wasn't as ubiquitous. If you wanted to work on some code while you were traveling or at a cafe or something, you'd at best be working without version control, making ".backup" files and directories and stuff. With DVCSes you could branch, commit, etc. as much as you wanted, then sync up when you got back somewhere with good internet.
This was not my recollection. The big thing about git over subversion at the time (at least before everyone started putting their repos up on github with pull requests and all) is that it was truly distributed i.e everyone maintained their copy of a repo and no repo was the 'master' or privileged source of truth. And merging changes was/is relatively seamless with fine grained control over what you want to merge in to your copy that svn simply didn't provide. Svn on the other hand is a server/client architecture. Although you could have multiple servers, it was kind of pointless as keeping them in sync was more trouble than it was worth. For most workflows there was the server or master repo and your local copy is not under source control. And if that master/server should go offline for any reason you were not able to 'check-in' code. I remember this being such a pain point because if the master was offline for a significant amount of time you essentially had no way to track changes you made and it would all just be one big commit at the end (which was also a major pain for the administrator/repo maintainer who would have to merge in a whole bunch of big breaking changes all at once). Maybe git vs mercurial was a close fight with no immediately obvious winner, but subversion's days were pretty much numbered once git showed up.
I never had the time (thankfully) to get good at Subversion. But now that I’ve “internalised [the pain]” of a DVCS I could never go back to a centralized VCS. Interacting with a server just to check the log? Either promiscuously share everything I do with the server or layer some kind of second-order VCS on top of Subversion just to get the privilege of local and private-to-me development? Perish the thought.
SVN is fine as long as you don't have multiple people editing the same file in the same time. In that case, generally one person gets his work overwritten. Committing on SVN is basically the equivalent of "git push --force".
Git clients became popular interfaces to SVN. This is how the organizations I was at moved from svn to git -- we/devs started preferring git locally and eventually migrated the backends to match.
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.