Dropbox and OneDrive do this nowadays, in that I can just right click a file and see the different versions and change to a previous one. I work with long documents I write, and this functionality has saved the day a few times.
https://github.com/johnsonjh/PC-DCL
patch: https://0x0.st/XoDG.patch
git clone https://github.com/johnsonjh/PC-DCL
cd PC-DCL
wget -O corr.patch https://0x0.st/XoDG.patch
git apply corr.patch
make NDBUG=1
From what I understand, BTRFS snapshots are time-based. Whereas, in classic versioned file systems, a "snapshot" is triggered by open/close operations – each time you open a file for writing, that creates a new snapshot.
> or you could use Git on top of the FS
Git requires your application to have explicit support for working with Git repos, it isn't seamless. And I know some people have built FUSE-on-Git implementations (there are a few around), but (I believe) they've all got various limitations and I don't believe (I could be wrong) that any of them is quite the same experience as a true versioned filesystem
With these caveats, using FUSE it should be easy to do, wonder why noone actually implemented it.
Classic versioned file systems were generally not designed for the use case of databases, they were designed for the use case of lots of small text files (config files, source code, shell scripts, etc). For something like a database file you would turn versioning off
I know about https://github.com/rroart/freevms/tree/master/dcl/src but my impression was FreeVMS is too incomplete to use in anger.
> I've seen things like mpsh
You mean https://cca.org/mpsh/ ? I am wondering how close it is to DCL, in terms of the specific aspect of it I’m talking about here
> and the ITS debugger/shell (DDT) ported to Unix...
Do you have a link?
One aspect of ITS I find fascinating is a debugged program can execute debugger commands. I actually implemented that before using a GDB Python script - have a do-nothing function passed a memory buffer containing a GDB command go run, the Python script sets a breakpoint on the function, and when that breakpoint is hit, it runs the GDB command, it can even write the results back into the buffer, and then it continues execution
https://github.com/johnsonjh/PC-DCL
DDT, I think Lars Brinkoff had a port:
[0] https://tvtropes.org/pmwiki/pmwiki.php/Literature/WizBiz
JSON is a serialisation of structured data, not structured data itself.
Its data model is not great, either: maps have no inherent canonical serialisation (one has to assert things such as ‘keys are sorted in Unicode lexicographical order’), and there is no way to shadow map value.
A list-based s-expression format would be preferable, as it immediately lends itself to canonicalisation and associative lists support shadowing (e.g. ((a 123) (b 456) (a 789))).
We have git, which is strictly better.
> Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink()
You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too.
> and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself.
I like not having to rely on arbitrary commands implementing (or not) wildcards.
(Plus, even in the best of worlds, all commands would implement wildcards by linking in the same library, which brings us back to square one.)
> You'd be complaining about how a really_really_unlink_now_i_mean_it() syscall was irreversible, too.
Or the converse; what file (or worse hundreds/thousands of files) is using up all my disk and what's the sane way to delete all the old versions, and which files are important to keep all the old versions of?
> I like not having to rely on arbitrary commands implementing (or not) wildcards.
Indeed and being able to use meta tools like xargs. "The unreasonable effectiveness of plain text".
Linux does have that in NILFS2, it's just that almost nobody cares to use it: https://www.kernel.org/doc/html/latest/filesystems/nilfs2.ht... / https://man.archlinux.org/man/nilfs.8.en
I don’t believe that NILFS2 is quite the same thing.
In HTFS, you turn versioning on or off on a per-directory basis, and then each individual file in that directory is versioned independently.
NILFS2 looks more like whole filesystem snapshotting, which is further away from the classic versioned filesystem approach
(1) Unlike OpenVMS/TOPS-20/LispMachines/etc, mainstream POSIX file systems lack built-in versioning (there are a small number of POSIX systems which implemented it, e.g. SCO OpenServer's HTFS, but for whatever reason more mainstream systems like Linux or *BSD never did)
(2) Directly related to (1), the fact that the unlink() system call is normally irreversible, and the rm command is (normally) a direct interface to unlink()
(3) The simplicity of the interface between the shell and the commands it runs (just a list of strings, only slightly better than the DOS/Windows approach of a single string), and the potential issues induced by the fact that wildcards are implemented by the shell not the command itself.
Regarding (3), OpenVMS DCL, IBM OS/400 and Microsoft PowerShell are all examples of systems where option parsing/etc happens in the shell, and the command is passed a parsed command line structure instead. However, although they are better in this regard, they have other disadvantages (the first two are super-proprietary; PowerShell is open source, but weighed down by the heaviness of .Net)
I think a lot of historical issues with Unix are due to the fact that shared libraries didn't exist until much later, so seemingly obvious things like "put wildcard parsing in a shared library like getopt() is" weren't possible at the start. Also, Unix has never had any kind of standard structured data format (JSON would work, but it didn't exist for the first 30 years of Unix's existence), which is a problem for ideas like passing command arguments as structured data.
> But then the terminal/TTY situation has barely changed,
POSIX TTYs are a horrific pile of kludges, especially when one considers stuff like ECMA-48 (which isn't technically part of the POSIX TTY stack, but de facto is). Someone should just redo it as something more sensible, like exchanging null-terminated JSON packets. But getting everyone to agree on that is probably too hard.