For a while I was infatuated with Plan 9. I used it off-and-on in a virtual machine for a while but using a virtual machine got me down. I installed it on a real machine but the real machine was really slow. I used 9vx on my laptop, but it was basically unusable without an external mouse plugged in at all times, because it relies heavily on having all three mouse buttons, and often, being able to press more than one of them at the same time. I used acme quite a bit despite all that, though.
Anyway, I was especially interested the idea of virtual filesystems, especially overlay filesystems. A virtual filesystem is in contrast to a concrete, disk-based filesystem where all the files map to bits on disk. It's sort of like the difference between procedural art and bitmaps; virtual filesystems might present directories and files that don't exist until you read them, with files that read forever or whose contents change with the time of day, always being regenerated based on input.
An overlay filesystem is one which presents files that exist in some filesystem below it, but with some useful change applied. For example, there is one that presents a filesystem with all spaces in filenames converted to underscores. There could be one that presents an existing directory, but with all Windows line breaks converted to Unix line breaks.
One of the most commonly recurring ideas for a virtual filesystem for Plan 9 (I've been subscribed to their mailing list for a long time) is an overlay that does version control. Eventually I became interested in the problem too, because the pitfalls of most proposals isn't that they don't work—it's that they're complicated and harder to use than an existing tool, without having any advantages. They're just different.
.patches
Imagine you're working in a directory and suddenly decide that you want to track changes. It's not that you necessarily want those changes tracked forever; maybe you're about to run some script and you want to be able to undo if it screws up. You'd run a command like this:
$ patches mydir/
The only visible change would be that a new (virtual) directory would appear named mydir/.patches/ with nothing in it.
Then you start making changes to files. After the first change, a file named mydir/.patches/current appears. Its contents are the output of diff comparing the original state of the directory with its current state. As you make changes, the file grows so you can track everything you've done. The files on disk have changed, but patches remembers where you were when you started.
This by itself is already pretty useful because there are many file operations that you can perform on current whose effects make sense. If you delete the file, the changes should be reverted. If you edit the diff, to tweak history or delete changes you don't want, those edits should be reflected. If you append another diff to that file, they should merge.
The next thing you would want to do is to add checkpoints (i.e. commits). Just rename mydir/.patches/current to something like mydir/.patches/first-draft. A file named mydir/.patches/history will also appear with contents like this, specifying the name of the patch and the date it was created:
first-draft 2011-08-02
In fact, only the filename at the start of the line matters; you can edit the file to remove the date or add a comment or whatever. Maybe the configuration file format Plan 9 uses would be more appropriate.
At any rate, the history file grows as you save patches, lines being appended each time you rename current.
When you rename a patch, hopefully that can be detected as a rename instead of the creation of a new patch. Also, if you add a bang '!' to the front of a patch name, its changes should be reverted, but its entry left in the history file. This seems to be a Plan 9 convention and it makes sense here.
So there you have it.
Error handling
Most of the commands can fail if you provide bad data:
- If you edit a diff, it might no longer apply, or you might have gotten the syntax wrong.
- If you delete or disable an old patch, newer patches may no longer apply. If you append a diff to a patch, it may not apply.
- If files are changed outside the overlay, all sorts of terrible things can happen.
I believe those can all technically be handled by causing the corresponding writes to the filesystem to fail, but it's unclear that the provided error message will always be visible to the user, and I'm not sure that there are always messages associated with the errors. If the errors appear in that floaty overlay text where most system messages in Plan 9 go, you know, the text that disappears the next time the screen redraws, then they would be quite useless. ;p