On Thu, 2006-10-05 at 16:08 -0700, David Dyer-Bennet wrote: > On 10/5/06, Erik Trimble <[EMAIL PROTECTED]> wrote: > > > Doing versioning at the file-system layer allows block-level changes to > > be stored, so it doesn't consume enormous amounts of extra space. In > > fact, it's more efficient than any versioning software (CVS, SVN, > > teamware, etc) for storing versions. > > Comparing to cvs/svn misses the point; as I said, they address > comletely different needs. > I was making a general point, to make it clear FS versioning isn't a disk pig.
> > However, there are three BIG drawbacks for using versioning in your FS > > (that assumes that it is a tunable parameter and can be turned off for a > > FS when not desired): > > > > (1) File listing symantics become a bit of a mess. VMS stores versions > > as <filename>;<version> That is, it uses the semi-colon as a > > divider. Now, I'm not at all sure how we can make ZFS POSIX-compliant > > and still do something like this. Versioning filesystems tend to be a > > complete mess - it is hard to present usable information about which > > versions are available, and at the same time keep things clean. Even > > keeping versions in a hidden dir (say .zfs_versions) in each directory > > still leaves that directory filled with a huge mess of files. > > "Complete mess" is certainly not my experience (I worked with TOPS-20 > from 1977 to 1985 and VMS from 1979 to 1985). The key is that you > need to *clean up*; specifically, you need to use the command which > deletes all but the most recent copy of each file in a directory at > the end of pretty much each work session. > > It's trivial to present information on which versions are available; > you simply list each one as a file, which has the date info any file > has, and the version number. > I stand by the "complete mess" statement. _You_ have trained yourself to get around the problem, by eliminating most of the reason for file versioning - you delete everything when you log out. A normal user (or even, most scripts) aren't going to do this. Indeed, I would argue that it makes no sense to implement versioning if all you are going to use it for is on a per-session basis. And, try thinking of a directory with a few dozen files in it, each with a dozen or more versions. that's hideous, from a normal user standpoint. VMS's implementation of <filename>;<version> is completely unwieldy if you have more than a few files, or more than a few versions. And, in modern typical use, it is _highly_ likely both will be true. > > (2) File Versioning is no replacement for source code control, as you > > miss all the extra features (tagging, branching, comments, etc) that go > > with a file version check-in. > > It's very definitely not an alternative or replacement for source code > control, no. It provides a very useful feature to use *alongside* > source control. Source code control is also not a replacement for > file versioning (I end up creating spare copies of files with funny > names for things I'd otherwise get from versioning; and I end up > losing time through not having through to create such a file, whereas > versioning is automatic). File versioning would certainly be nice in many cases, but I think it's better implemented in the application (think of Photoshop's unlimited undo feature, though better than that), than in the FS, where it creates a whole lot of clutter and confusion real fast, where it is only specifically useful for a very limited selection of files. > > (3) Many apps continuously save either temp copies or actual copies of > > the file you are working on. This leads to a version explosion, where > > you end up with 100s of versions of a commonly used file. This tends to > > be worse than useless, as people have an incredibly hard time figuring > > out which (older) version they might actually want to look at. And, > > this problem ISN'T ever going to go away, as it would require apps to > > understand filesystem features for ZFS, which isn't going to happen. > > Files treated that way are often deleted at the end of the session > automatically, so no problem there. Or else they'll be cleaned up > when you do your session-end cleanup. What the heck was that command > on TOPS-20 anyway? Maybe "purge"? Sorry, 20-year-old memories are > fuzzy on some details. So, here's a question: if I delete file X;1, do I delete X;x ? That is, do I delete all versions of a file when I delete the actual file? what about deleting a (non-head) version? And, exactly how many different files have to be cleaned up when you logout? How does this get configured? Who does the configuring? What if I _want_ versions of some files, but not the others? And, what about network-sharing? For non-interactive use? (i.e. via SAMBA, or other apps where you're not looking at the FS via a command prompt?) > File versioning worked a lot better on TOPS-20 than on VMS, as I > remember it. The facility looked the same, but actually working with > it was much cleaner and easier. > > Making it somewhat controllable would be useful. Starting with maybe > an inheritable default, so some directory trees could be set not to > version. > > > I'd discourage File Versioning at this late stage in UNIX. Source Code > > control systems fulfill the need for serious uses, and casual usage is > > obviated by the mantra of "save early, save often" that has been beaten > > into the userbase. Trying to change that is a recipe for disaster. > > Actually, "save early and often" is exactly why versioning is > important. If you discover you've gone down a blind alley in some > code, it makes it easy to get back to the earlier spots. This, in my > experience, happens at a detail level where you won't (in fact can't) > be doing checkins to version control. Then, IMHO, you aren't using VC properly. File Versioning should NEVER, EVER, EVER be used for anything around VC. It might be useful for places VC isn't traditionally use (Office documents, small scripts, etc.), but the example you provide is one which is easily solved by use of frequent checkins to VC - indeed, that's what VC is supposed to be for. File versioning is really only useful when we can hide the versioning mess from the end-user, and yet provide them with some reasonable mechanism for accessing the file versions if need be. And we keep versions around, period. I don't see that as being possible using the traditional UNIX/POSIX filesystem layout. Like I said before, maybe when the FS becomes a RDBMS, but even then... -- Erik Trimble Java System Support Mailstop: usca14-102 Phone: x17195 Santa Clara, CA Timezone: US/Pacific (GMT-0800) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
