> It should be obvious that I love SCCS, it's a dramatically better file format than a patch based one, you can get any version of the file in constant time, authorship can be preserved across versions, it's pretty brilliant and I consider myself blessed to be posting this in response to SCCS's creator.

I have seen Larry make similar claims about the weave format vs. patch-based format many times, and he has also put git firmly in the "patch-based" camp, but I believe the only real effect to git not using a weave is increased time-complexity of "blame" operations.

1. Git has constant time access any version of a file as well; the --depth option to the pack algorithm places a constant (but configurable) upper bound on the number of deltas that will need to be applied whenever fetching a blob. Intuitively, it would seem to me that for files with extremely large numbers of changes, this could be faster than extracting the weave, potentially at reduced space efficiency.

2. Merges are separate from the commits that effect the change; the lm/clem example in TFA would work as expected on git. Merge commits will only show up in the annotation if there were conflicts.

I got into unix after CVS had pretty much displaced SCCS and RCS, but the older per-file version control systems persisted long enough that I had a few close encounters with them.

When I took over Cambridge University’s DNS, its code and configuration was still in SCCS, because that was what shipped with SunOS in 1991ish. I converted the SCCS archive via RCS and CVS to git – https://dotat.at/@/2014-11-27-uplift-from-sccs-to-git.html – which was a fairly entertaining exercise. (Sadly the links in that blog post are mostly broken.) I even used those conversion scripts more than once! https://dotat.at/@/2016-07-19-uplift-from-sccs-to-git-again.... (That repository ended up with at least three distinct root commits, one for the main DNS history, one for the Ansible setup that started with DHCP and later grew to handle DNS too, and later the separate vanity domain DNS setup.)

I once had one of my users come to me: "I accidentally typed "ci filename" rather than "vi filename", it asked me some questions and I answered them, and now my file is gone." I told her: "Don't worry, I know exactly what happened and how to fix it!" She was one of that day's Lucky 10,000.

The SCCS "weave" data structure is indeed poorly-understood; and what almost nobody knows is that it's equivalent to a text CRDT!

https://braid.org/meeting-60/sccs-is-a-time-collapse

TUHS = The Unix Heritage Society

* https://www.tuhs.org

* https://en.wikipedia.org/wiki/Ancient_UNIX#The_Unix_Heritage...

We still use SCCS at the investment firm I work at, to track configuration file change history.

The source code itself was moved to Subversion (via RCS and CVS) long ago, and later to Git, but the configuration files continue to be tracked using SCCS.

There is an open source implementation of SCCS called GNU CSSC: https://www.gnu.org/software/cssc/

For those that don't know, Larry was the author of BitKeeper and when he changed the license for it, it prompted Linus to write Git. Guessing if he had never done that, we'd all be using BitKeeper now and Git wouldn't exist.

I remember moving some code stored in SCCS from unix to a (microsoft) xenix machine. But the compilation broke and I had to track down what was going wrong.

I finally found out the probelem, which was part sccs and part xenix.

xenix had shorter filenames, so while checking filename.c into SCCS gave s.filename.c, checking longfilename.c into sccs gave s.longfilename and checking it out lost the .c extension and make wouldn't compile it.

Server is hanging up on me for some reason. Posting an archive link in case anyone else has this problem.

https://web.archive.org/web/20241213205017/https://www.tuhs....

I still want to set up a copy of TeamWare SCCS… it seems to have several SunOS specific expansion extensions that are prevalent in many Solaris source files (such as %Z).

https://en.m.wikipedia.org/wiki/Sun_WorkShop_TeamWare