I started with SCCS, then moved to RCS, then to CVS for a long while. I'm now an occasional Git user. The number one problem with SCCS is a locked checkout paradigm: one person gets to edit at a time. Also, it doesn't manage directories, only files. Read here for some alternatives: https://en.m.wikipedia.org/wiki/Comparison_of_version_contro...
Here's what Verity Stob has to say about vcses of that era: "Thus the workflow was: connect to the archive, check out and lock a good selection of vital files, edit them a bit, then depart for two weeks in Corfu without releasing locks, secure in the knowledge that, short of guessing your password, any progress on the project by colleagues was effectively prevented. Marvellous.". :-)
In the "old days" people were used to the locked checkout scheme, and we were afraid of merges. In a large code base most people were working on different files, so lock conflicts ("I want to edit a file but somebody else has it checked out") were fairly rare.
We used SCCS on a shared filesystem. If you really needed to edit a file somebody else had locked, you simply removed the lock file. Of course, social convention was that you better have a really good reason for doing that. If you went on vacation with files locked, it was pretty much expected that your locks would be removed, and that you'd have to merge or otherwise deal with your stranded edits.
I've worked with both SCCS, RCS, Perforce and git. The way SCCS and RCS did it was a pain, but Perforce's was IMO more feature than bug. When Perforce told me "uh, X is editing this file you're just about to edit", talking to X was usually a good idea for some reason I wasn't aware of. Sometimes X was working on one issue and I on another, and the deeper cause was actually the same. Sometimes X had forgotten to check in some work and would do so immediately when I asked.
Not always. But often enough that I liked those locks. (Hated the RCS/SCCS locks though. Those had far too much cost and offered too little value.)
Sometimes locking out files on complex changes has a better outcome than a modify-merge cycle I have found. This doesn't scale out to lots of engineers however.
If you're doing critical heavy lifting or refactoring, merging inline changes is hell.
Every team I’ve worked with has had an informal locking method that gets used for really disruptive work. Instead of locking files in the VCS, you tell everybody that you’re going to be doing X, try not to make changes around that, and coordinate with that person if you really need to make changes on the same stuff.
I think the informal technique works better since it’s a lot more flexible, but the basic concept is very useful.
