Multiple file versions - more light, less heat

[Dick Dunn]

> 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!