leichterj@rani.DEC (09/23/84)
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
dave@uwvax.ARPA (Dave Cohrs) (09/24/84)
What ever happened to sccs or rcs? It seems that these systems
give you the features of versions that people want (log of
changes, recovery of old versions) without lots of extra
disk usage. Plus, they are already available for UN*X systems
without putting even more junk in the kernel.
--
Dave Cohrs @ wisconsin
...!{allegra,heurikon,ihnp4,seismo,ucbvax,uwm-evax}!uwvax!dave
dave@wisc-rsch.arpagwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (09/25/84)
Whether "VMS is pretty clearly the winner" re. multiple file versions must be a matter of taste. I did development work on RSX & VMS before UNIX and I loath and detest automatic file version generation. It is hard to see how this could be made to work sensibly in the context of inodes and links, anyhow.
rcd@opus.UUCP (Dick Dunn) (09/25/84)
> 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. With a blanket statement like that, it's hard to know whether my posting (which took a moderately strong anti-VMS anti-version stance) falls under the condemnation. I'll assume that it does, more or less. I don't see that it's at all evident that file versions are "a good thing", per se. They solve some problems but they can get in the way. Other (mostly older) DEC systems used a scheme in which editors would rename a file abc.xxx (where xxx=almost anything) to abc.bak at the start of editing. This gave exactly one extra version of the file. It had some obvious drawbacks: - the ".bak" transformation was subject to some funnies--if you had abc.for and abc.txt, editing either would create abc.bak and destroy the .bak file for the other. - .bak had to be implemented by every editor or other program which intended to create a backup file. The version mechanism is built into VMS at a lower level, where it's transparent to most programs--fine. This means that everyone doesn't have to reinvent it (potentially incorrectly). But correspondingly, it means that you get multiple versions of every file whether you want them or not. (Yes, I know, there are controls. That's just more complexity to control the extra feature. If I'm working on a program, I'm not going to figure out how to set it up so that I don't get multiple versions of my .obj files.) > 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*... This is a complete non-sequitur. No OS (even VMS:-) will do what you WANTED it to unless, perchance, you actually told it to do so. I don't know about hundreds of files, but I HAVE generated several dozen in a very short time. And even if it's simple to get rid of them, you still have to do so periodically. It's just one more thing to remember, like remembering to write the edit buffer to the file now and then (if you've got one of those editors hypertuned to keep everything in memory forever). > 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. Not clear in the least. VMS is the winner IF you want or need file versions. I didn't find them to be particularly useful. In fact, I found that there are some naive assumptions about file versions in a couple of pieces of (admittedly poorly written) software which made the filesystem LESS reliable with versions. These are my own experiences, as a user of both VMS and UNIX. I'm not trying to say that file versions are a bad idea; they just aren't a universally good idea and an OS designer might think twice before building them into a system. -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Cerebus for dictator!