pathnames

[Chris Bitmead uid]

>After years of using both VMS system (which has versioning in the
>file system) and UNIX (which does not).  I'd say that although the
>basic file system versioning doesn't meet all application scenarios,
>I MUCH prefer "magical" file system versioning to not having it at
>all.  I think the ability to generally be able to go back a few
>a few versions to see log files, old config files, old source code,
>etc. is a big win and perhaps the reason VMS systems are so reliable.
>When there is some odd problem, it's usually possible to back up 
>to previous versions of files to see the state of the system as 
>captured in the files.  
>
>Sure, it's possible to imagine a system where all applications handle 
>their own versioning with the versioning built into the different 
>object types, but even here I see no reason not to back this up with file
>system versioning.  It may be >ideal< to have application level
>versioning, but why >not< have file system versioning too?  Usually,
>file system versioning is good enough for application log files, a
>very common versioning application.  When it's not, extend it with
>application level versioning.

The thing about LispOS is that there isn't this big partitiion between
the "OS" realm of responsibility and the "application" realm of
responsibility.

Just because it is an application decision, doesn't mean that it
shouldn't use one of several different built-in, library, common
scenario versioning facilities.

I can imagine that several different versioning objects might be
written by people to handle different version situations. Applications
would inherit their objects from a versioning object base class that
does things the way they want.

That doesn't mean it is some fundamental part of the OS though. It
does mean that it is 5 seconds work to implement if when you want it
though.