I am not personally aware of any operating system in the entire history of computing ever having had this feature.
Siemens BS2000 of the early 1970s may be an example here (*1) with a feature they called file generations. A new file could be marked in the catalogue as having generations, setting a base generation number and how many generations are to be held (*2). It was presented by a single entry, and for most purpose handled like any other file.
To address any of the generations a file name could be suffixed with it's generation number. For example a file named "TEST.FILE" could be defined as holding up to 5 generations with generation 6..10 existing and generation 10 being the newest (actual). Valid names for file operations would be:
- "TEST.FILE" accesses the actual generation (#10)
- "TEST.FILE(9)" accesses the explicit generation #9
- "TEST.FILE(-1)" also accesses the generation before the actual (as well #9)
The actual generation (pointer) could be moved using shell commands and/or an API. For example to revert to a previous version. If in our example it would be set to 8, then
- "TEST.FILE" accesses the actual generation (#8)
- "TEST.FILE(-1)" also accesses the generation before the actual (#7)
- "TEST.FILE(+1)" also accesses the generation after the actual (#9)
This mechanism makes it easy to handle things like logfiles, program versions or databases. Roll-back or roll-forward can be done by a simple command and unlike any naming scheme, no program has to be modified to work with file generations - that is, unless some special features are to be used - all they see is a regular file.
Unix was written an extremely long time ago. As I understand it, in Those Days a "large" system might have as much as 2 Kwords of memory, [...]
Erm, these were the smallest systems. Keep in mind, a PDP of that time was the lowest end of computer available. The upper end, where 'real' OSes were used, was quite different. For example, the database system used for the 1972 summer Olympics used two mainframes with 2 MiB of core memory each and more than 30 disk drives of 77 MiB each (*3). Those were large systems (*4). Not PDPs.
Admittedly, such a configuration is close to the upper limit what was used at the time, but it wasn't a unique installation.
I find it very hard to believe that a system with a 4 Kword disk would "waste" disk space by keeping every prior version of every file ever created. That just seems like you'd run out of disk space inside of ten minutes.
Like with many other features, they are only useful on a capable setup, the same way that subdirectories only make sense with drives large enough to hold them and so on. Equally important, features only make sense from an application viewpoint. An application needing do hold versions will love an OS that supports it in a consistent way.
Bottom line: Developing an OS's capabilities orientated at the smallest possible configuration doesn't sound like a good idea, or does it?
Have I misunderstood what they're talking about? Or were there actually systems that worked like that?
Quite a lot. In the mid '70s it was seen as a great addition to extend the usability of file systems. At that time many features we would nowadays place request from a database system were provided directly by OS and file system.
Oh, and it's not only a thing of the past. IBM zOS for example does as well support their mechanic of file versions, called a Generation Data Group.
*1 - BS2000 was based on RCA's TSOS, but I'm not sure how much was already present in TSOS.
*2 - This includes tape storage, so generations could be moved to tape for long term storage (and to save disk space). The catalogue would still be used to manage them.
*3 - Yes, that's in total about 2 GiB in 1972 :))
*4 - That view, users of 'real' computers had on Unix is reflected in the Unix Hater's Handbook, isn't it?