On 10/6/06, Erik Trimble <[EMAIL PROTECTED]> wrote:
First of all, let's agree that this discussion of File Versioning makes no more reference to its usage as Version Control. That is, we aren't going to talk about it being useful for source code, other than in the context where a source code file is a document, like any other text document. File Versioning and Version Control are separate things, with different purposes and feature sets.
Hmm; the most important uses of file versioning come, in my opinion, when working on source code. But for handling very different situations than source control does.
OK. So, now we're on to FV. As Nico pointed out, FV is going to need a new API. Using the VMS convention of simply creating file names with a version string afterwards is unacceptible, as it creates enormous directory pollution, not to mention user confusion. So, FV has to be invisible to non-aware programs.
Strongly disagree, twice. Having FV invisible to programs not updated to specially support it is IMHO unacceptable, and would render the feature useless. I remember it being a bit inconvenient on VMS. It wasn't on TOPS-20. I'll have to look into what the TOPS-20 conventions were again (I used TOPS-20 from 1977 to 1985, but hardly touched it since), but I found them very friendly and easy to work with, not confusing, etc. They weren't *that* different from the VMS approach, but this is probably one of those situations where tiny tweaks to user interface make a huge difference to user experience.
Also, FV is only useful for apps which do a "close()" on a file (or at least, I'm assuming we wait for a file to signal that it is closed before taking a version - otherwise, we do what? take a version every X minutes while the file still open? I shudder to think about the implementation of this, and its implications...). How many apps keep a file open for a long period of time? FV isn't useful to them, only an "unlimited undo" functionality INSIDE the app.
It's the rewrite scenario; when we open or rename a file on top of an existing file, the new file gets an incremented version number, and the old file stays around.
Lastly, consider the additional storage requirement of FV, and exactly how much utility you gain for sacrificing disk space.
It was something we could afford, and did afford, on TOPS-20 systems where having three RP06 disk pack systems (at 200MB each) was considered rather a lot of storage. Today it's a complete non-issue. Disk space is free.
To me, FV is/was very useful in TOPS-20 and VMS, where you were looking at a system DESIGNED with the idea in mind, already have a user base trained to use and expect it, and virtually all usage was local (i.e. no network filesharing). None of this is true in the UNIX/POSIX world.
When TOPS-20 was introduced, essentially nobody was used to file versioning. When VMS was introduced, very few people were used to file versioning (and the TOPS-20 community mostly moved to Unix rather than VMS). TOPS-20 wasn't the first system I used (it was the fifth, Ithink), or even the first timesharing system (the third, I believe). File versioning was one of those "instant love" features; it was instantly obvious how it worked, how to use it, and how beneficial it was. I see network file access as a non-issue; the version gets treated as part of the file name, just as it did on all the previous systems that supported file versioning. I'm *still* not really sure it's actually worth the trouble of adding, if 5-second snapshots are really feasible. They're less convenient to use by quite a bit, but the important use cases arise relatively rarely, and the value is high when they arise, so that's not *too* big an issue. And more code complexity and more user confusion (I don't think versioning is terribly comlex to understand, but certainly snapshots plus versioning is more complex than snapshots alone). But if people are going to decide against file versioning, I'd prefer it to be based on a more accurate understanding of how it plays to users :-). -- David Dyer-Bennet, <mailto:[EMAIL PROTECTED]>, <http://www.dd-b.net/dd-b/> RKBA: <http://www.dd-b.net/carry/> Pics: <http://www.dd-b.net/dd-b/SnapshotAlbum/> Dragaera/Steven Brust: <http://dragaera.info/> _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
