I seem to remember that one could configure the max. number of versions VMS would retain for you on a per-file basis - setting this to 1 would de facto turn off versioning. IFF versioning were implemented in ZFS, AND was made configurable on a per-file basis (everything else wouldn't make any sense at all, IMO), the default could be set to 1, to avoid the various horror scenarios that have been painted here, and people could increase the number of versions they want for those files that need it.

cheers
Michael

Chad Leigh -- Shire.Net LLC wrote:

On Oct 5, 2006, at 5:40 PM, Erik Trimble wrote:

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,

No it is not. I worked for DEC and used VMS up through 1993 and never found it unwieldy. Even if I had 100 versions of one file. It is

1) what you are used to

2) what you are trained to do

that makes it unwieldy or not

I find the "unix" conventions of storying a file and file~ or any of the other myriad billion ways of doing it that each app has invented to be much more unwieldy.

Yes, you have to "purge" your directories once in a while. The same way you have to clean up any file "mess" you make on you computer (download area, desktop, etc).

or more than a few versions. And, in
modern typical use, it is _highly_ likely both will be true.

So what if you have more than a few versions of a file.

Beauty is in the eye of the beholder, and just because YOU find it unwieldy does not make it so for the general user or anyone else.

I would LOVE to have a VMS style (sorry, my TOPS-20 usage was very little so I have no remembrance of it there) file versioning built in to the system.

"save early, save often" ONLY makes sense with a file versioning system, or else you lose previous edits if you decide you have gone down a wrong alley.

Chad

---
Chad Leigh -- Shire.Net LLC
Your Web App and Email hosting provider
chad at shire.net




------------------------------------------------------------------------

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


--
Michael Schuster                  +49 89 46008-2974 / x62974
Recursion, n.: see 'Recursion'
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to