Re: version numbers, NFILE, Suns and CHAOSnet

["Robert W. Kerns" <RWK@scrc-yukon.arpa>]

    Date: Thu, 19 Nov 87 23:45:34 -0500
    From: Rayan Zachariassen <rayan%ai.toronto.edu@RELAY.CS.NET>

    # You could also use a filesystem with version numbers.  I cannot
    # understand how, in this day and age, people still advocate a
    # filesystem which has not caught up with the 1960's.

    Never having lived on a filesystem with version numbers (except on lispm's,
    where I mostly turn it off), it isn't clear to me why this is a good philosophy.
    Could someone enlighten natives of the non-version number filesystems?

If the natives will refrain from sticking pins in my ankles, I will
try.

    I recognize that having version numbers is a generalization of a filesystem
    without version numbers, but what are the overhead costs, and are they
    worthwhile compared to other approaches (from both system & user pt. of view)?
    What do people use it for, that makes it worthwhile?

The overhead of version numbers is as small or as large as you
like.  It doesn't take any more run-time to write a file
in a system with or without version numbers.  It *may* take
more file space.

You have all of the options with version numbers that you do
without.

You can just write to a single version of the file (say, version 1).
This is just like Unix.  Once you've written a file, if you decide
you made a mistake, you're dead.  This policy is so disasterous that
all modern Unix editors provide one way or another to let you save
at least one older copy.  However, this is only done in the editors;
most programs don't provide this.  Clearly, it should be a uniform
policy throughout the system, and individual programs should not have
to reimplement it for themselves.

You can write to .NEWEST, but set the generation-retention count to 1.
Only the newest version will be retained, although until an expunge
operation is done, you can undelete the old ones.

The cost here is the space consumed by these
deleted-but-not-yet-expunged files.  This space can be recovered by
manually expunging, by automatically expunging the directory
periodically, or by manually expunging the entire file system.
(Note that the Unix editors don't provide the flexibility of automatically
reclaiming the backup copies).

Or you can set the generation-retention count to some value larger
than 1, or not set it at all, in which case you'll pay for the disk
space consumed by these additional (undeleted) files.

Offsetting these costs are several advantages:

* You have a chance to recover from your mistakes.  Your time is more
  valuable than disk space ... and data may be irreplacable!
* The filename reflects the difference between two different versions of
  the file.  Instead of renaming a file to be under a backup name, with
  version numbers, a file normally retains its name throughout its life.
  Thus you can note that version 357 is current right now, and later come
  back and see that version 360 is current, and think to yourself, "Ah,
  three edits have been made.  Let me do a source-compare and see what
  they were."  It's harder to do this if all you have to go on are the
  creation dates.
* Different versions of the file can coexist.  No need to move them to
  another directory.  SCT makes use of this to allow loading specific
  versions of a system.
* If you set the generation-retention count above 1, you have an audit
  trail you can follow back to see what changes have been made.  This
  is often provided by "source control" tools, but with version numbers,
  this capability is available for 1all0 files.

In short, it gives you a lot of capabilities, at the cost of having to
pay a little closer attention to cleaning up after yourself.  But then,
which is more valuable; disk space, or programmer (or user), and hence
workstation, time?

But the best part about it is that it protects you against all your
mistakes, not just the ones you make with the editor.