Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site decwrl.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxj!houxm!ihnp4!zehntel!dual!amd!decwrl!dec-rhea!dec-rani!leichterj From: leichterj@rani.DEC Newsgroups: net.unix-wizards Subject: Multiple file versions - more light, less heat Message-ID: <3713@decwrl.UUCP> Date: Sun, 23-Sep-84 16:02:54 EDT Article-I.D.: decwrl.3713 Posted: Sun Sep 23 16:02:54 1984 Date-Received: Wed, 26-Sep-84 06:11:28 EDT Sender: daemon@decwrl.UUCP Organization: DEC Engineering Network Lines: 46 As usual, those who believe that not only does Unix have good ideas, it has ALL the good idesa; and, not only does VMS have some bad ideas, it has nothing but; have managed to produce a great deal of heat on the issue of multiple file versions, and displayed little understanding. Here is how the multiple file version feature actually works. Any VMS file spec can optionally have a file version. If you specify a positive integer as a file version, you get that particular version. If you specify a negative inte- ger, you get a "recent" version: -1 is the next-most-recent, -2 the one before that, etc. (These ignore actual version numbers; if you have foo.bar;5 and foo.bar;100, foo.bar;-1 is the same as foo.bar;5.) If you leave off the version number, there are defaults. In just aout every case, an input file will default to the most recent version, and an output file will default to a version num- bered one higher than the current highest. (The exceptions are VERY few, and in very special situations. I can think of only two examples: DELETE demands an explicit version number (which can be *) - since the obvious default of "most recent" is most likely not what you want; and DIFFER (like Unix diff), if given only one input file, compares that file to it's most recent ancestor. (That is, if I've just editted foo.c, DIFFER foo.c compares my new version to the original.) It's been remarked that the VMS multiple version facility leads you to filling your directory with hundreds of version of files. This is actually a rather interesting criticism from a Unix point of view, since there are certainly many similar things in Unix where the OS refuses to "get in your way" - and will happily do an rm x * for you when you WANTED rm x*; but let's look a bit closer. What do you have to do when you decide you have too many versions? Nothing complex: Just type PURGE. All previous versions in the current directory disappear. You only want to get rid of old versions of foo.c? Fine, type PURGE FOO.C. Or PURGE FOO.* if you want to get rid of FOO.C version, FOO.OBJ versions, etc. You want to keep the three most recent versions? Do PURGE/KEEP:3? Further, in VMS you don't normally need find, since cross-directory wild-carding is built in: PURGE [...] purges this directory and all descendants. Finally, suppose you don't want to bother typing PURGE. Well, you can automate things: Every file has associated with it a settable paramater which is the version limit. When more than that many versions are created, the oldest ones get purged automatically. Further, you can specify a version limit for a directory; this becomes the default version limit for any files created in that directory. There are certainly things to criticise in VMS, and there are things to praise in Unix, but here I'm afraid VMS is pretty clearly the winner. -- Jerry