I think of revision control in the developer’s source-control sense and automatic file-system-based revisioning as serving different purposes, and solving different problems, even though they are the same “thing” and may be built on the same technology. When programming, a “check in” is usually a positive statement about a piece of work: “This file (or this set of files) is in a state that merits being recorded”. (Different groups and different projects will have different standards for what merits being recorded — e.g. some might require that a check-in compiles, some that it pass unit tests, others may be more free-wheeling, etc.). The stricter a given development’s team requirements for check-in-ability, the longer the potential time between check-ins. During those between check-in interstices a developer may be very happy to have the automatic revisions inherent in a filesystem. I know there have been times when I have changed my mind with respect to how I am implementing something, but not all the way back to the latest check-in, and have been glad for emacs’s automatic incremental file backups.

I admit that I haven’t crossed over to the new Macs, so don’t have a feel for how Time Machine works, though from what I’ve heard about it it reminds me of netapps snapshots (though snapshots don’t use a new disk).

Though it does seem like directories are an idea that is starting to, in some circumstances, outlive its usefulness; I know that, with my GTD tradition, I wish that I was using a mail client that was based on tagging instead of folders. But that’s another blog post…

I think they didn’t go quite far enough, there is no reason to restrict oneself to once a day. A modern journalling filesystem may have several copies of the same file already on disk. It might be fun to push this to see how far it could go by adopting a simple “never delete anything” mantra, but making use of “data deduplication” to avoid storing redundant blocks.