I am super curious about your experience with SCCS! I have never really used it for personal projects, so the blog post is purely based on research and a bit of trying. Really curious what oyu loved and what annoyed you about SCCS!
Collections of revisions were self managed as you say.
RCS came along and I think that’s where the $Id$ construct came in. This would expand to the version number of that particular file - if you const char * const idstr = “$Id$” then you could “strings” your binary and see what components were there. Of course, fileguard #ifdef’s would affect this.
Finally, CVS (maybe) had the idea of tagging, which would associate a single label across a current snapshot of different files and their versions.
In 1993-94, ClearCase came on the scene and tried monetizing this concept. A site license cost $30k in 1994 dollars and required a kernel patch for it to work. Try explaining that to your DEC, HP or Sun representative. The software implemented its own filesystem - you would set some kind of version label on a directory and then magically all files and sub folders would appear as of that date. This included libraries, binaries, data files, even crash dumps.
This is all from memory, someone can fact check and correct the finer details.
Nice blog post!
Systems like Clearcase is where “release manager” type roles were born. One poor guy would become the expert trying to bang a release out of it over weeks or months.
RCS had tags but they were single file tags; the two big things CVS gave you were "this collection of RCS files means something as a whole" (which made tags and branches meaningful) and "you can sort-of-efficiently update from a repo on the other side of the country". (The former was the entire point: CVS was written so Solbourne could maintain their multi-cpu-SunOS fork and still pull changes from upstream; the latter was from Cygnus having a similar upstream+local problem and developers distributed across the planet.)
Getting groups to move to CVS was hard. Devs were terrified of conflict resolution if they edited the same file concurrently as another dev. Took patient explaining that it would only be an issue if both devs modified the same lines, and even then it would guide you through the experience.
But they did let me, a young engineer, convert them from SCCS to CVS, so yay!
I have been a solid user of SCCS and successors since SCCS became available out of the box on SunOS.
The delget/deledit pessimistic model of SCCS (and RCS, and CVS?) were poor compared to newer VCSes such as SVN and git.
The pain of getting SCCS (and even RCS) to work for multiple networked users was ... well ... profitable for me at my hourly consultancy rate...
But even SCCS saved me/others from many traumas and detected file corruption (even a failing SCSI disc connection once, IIRC).
We switched to PVCS which made it easier to have isolated work spaces, plus a bunch of scripts to build those so developers could effectively emulate feature branches. Merging was a bit painful but at least you could work without holding other people up.
I’ve used other tools since but git is damn good compared to those older tools. I do miss being able to embed version strings but in reality tagging is superior if you have disciplined release control.
I also ran across SCCS for Linux somewhere, I forgot where I saw it. Maybe you can look for it and play with it.