Any version control where you had to manually (and globally) "check out" (lock) files for editing was terrible and near unusable above about 3 people.
Version control systems where you didn't have shallow branches ( and thus each "branch" took a full copy / disk space of files) were awful.
version control systems which would have corruption data-bases (Here's to you Visual source safe) were awful.
Subversion managed to do better on all those issues, but it still didn't adequately solve distributed working issues.
It also didn't help that people often configured SVN to run with the option to add global locks back in, because they didn't understand the benefit of letting two people edit the same file at the same time.
I have a soft-spot for SVN. It was a lot better than it got credit for, but git very much stole the wind from under its sails by solving distributed (and critically, disconnected/offline) workflows just a bit better that developers could overlook the much worse UX, which remains bad to this day.
>It also didn't help that people often configured SVN to run with the option to add global locks back in, because they didn't understand the benefit of letting two people edit the same file at the same time.
I think it was more that they were afraid that a merge might some day be non-trivial. Amazing how that fear goes away once you've actually had the experience.
(I had to check because of this thread. SVN and Git initial releases were apparently about 4 and a half years apart. I think it was probably about 6 years between the time I first used SVN and the time I first used Git.)
