[prosaic-hacker]

Early 80's VMS had a Keep/Purge system for history of files. Everytime you edited a file a version number was bumped up by 1. There was a command, "purge", I think that set the Keep count which was default to 3.

This would have been within the contemporary Dos and disk capabilities and size of 160-360kBytes, although slow (5-15 seconds).

When Dave Cutler moved from DEC to MS I expected the Dos console under windows to get that same feature. Disappointed. A gajillion lost hours could have be saved.

[sitkack]

We had a VMS machine in school and regret not spending more time learning from it.

It would be awesome to have application level granularity for a time traveling file system, the undo/redo mechanism could be built into the OS.

Reading up on https://en.wikipedia.org/wiki/Fossil_(file_system)

[kragen]

Incidentally, I was just reading https://cseweb.ucsd.edu/classes/wi19/cse221-a/papers/bobrow7... about TENEX, which offered roughly the same version numbering facility as VMS, though without the hierarchical filesystem directories VMS and Unix got from Multics. I don't know if TENEX got the idea from an earlier system. They don't mention one.

It's kind of amazing that this one paper introduced command-line completion, copy-on-write pages, load averages, and CAM TLBs.

[kragen]

The way I remember it, there was a SET command to set how many versions of a file should be kept, and PURGE would delete all but the most recent version. You could see the date of each version in DIR (they were listed on separate lines) but there wasn't a convenient way to open "FOO.FOR as of yesterday morning". You would have to figure out what version number to ask for and open "FOO.FOR;53" or whatever.

I agree that implementing this functionality in MS-DOS would have been relatively straightforward and acceptably efficient.

It'd be great to have long-lived transactions in a filesystem, permitting higher-level undo and redo.