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.
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.
(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).
(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. 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. -- 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
