I signed up for the ZFS discussion group over on OpenSolaris.org and have been following a fascinating thread about a versioning file system.

The discussion has been hot for several days. There is intelligent conversation about data preservation: CDP, snapshots, source control systems and file versioning among others. This is how features often get hammered out by engineering. The good news is that these guys are trying to grok the user experience.

File versions: the prequel
You know how everytime you edit a file in Windows, OS X or, I’m guessing, Linux, your saved file is now the only version of the file you have? It doesn’t have to be that way.

You could have the file create a new version of itself every time you edit it. So later, if you decide that fourth 321 Margarita wasn’t a good idea – it usually isn’t – you could go back to an earlier version, and begin again.

File versioning was standard on DEC’s VMS and TOPS-20 operating systems, and I really liked it. I could do radical things, secure in the knowledge that I could go home again.

ZFS file versioning
It doesn’t exist today, but the engineers are talking about. Here’s part of my favorite post so far, to give you a taste of the debate between two of the folks. I’ve put their comments into different typefaces so you can tell them apart:

Given this, we’re back into the problem FV is supposed to solve. It is entirely possible for an editor to keep open a file for a long time, periodically writing out your changes without issuing a new open().

You describe this as a problem, but *I* see it as the exact thing that makes file versioning useful. It DOESN'T save random magically chosen moments; it saves exactly all the version that *you*, the user, saved at some point of the editing session.

Word with auto-save turned off is a prime example. Given this, you’ve only created a new version when you first load the document, and all your intermediary changes are lost, since it only saves the document on close().

You're forgetting that the user, unless he's stupid, will save regularly during the editing session.

Thus, in order to get benefits from FV, your editor must issue periodic close() and open() commands on the same file, as you edit, all without your intervention. Exactly how many editors do this? I have no idea. So, the only way to enable FV is to require the user to periodically push the “Save” button. Which is how much more different than the current situation?

It is completely and utterly different from the current situation. In the current situation, when I type the "save" command *I am deleting a previous version*. That's dangerous, because people don't think of it as performing a destructive operation, and hence don't give it the care and consideration they give to an explicit "rm". And that's precisely what file versioning fixes; saving a file is no longer a destructive operation.

The second guy has the better argument
Not being an engineer I’m not sure how to enter the discussion, except to say I think versioning was a great idea 30 years ago and I still think it is a great idea today.