pathnames

Jordan Henderson jordan@Starbase.NeoSoft.COM
Fri, 16 May 1997 20:57:52 -0500 (CDT)


> 
> > I suggest that any versioning system based on magical file system
> > primitives is doomed to fail. Sure you can add functions to
> > explicitely say what you want to do in all these cases, but then the
> > system isn't a magical behind the scenes thing anymore. So why have it
> > as some built in primitive? Let people create a versioning system
> > appropriate to what _their_ application needs to do.
> 
> Hmmm... interesting scenario; I see what you mean.
> 

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.

I've had this argument a lot with people who think that UNIX is
perfect.  Arguing against file system versioning because it 
doesn't offer everything that application level versioning is
like arguing against files systems because they don't offer
everything that relational databases do.

In VMS, you can set file versioning on any file or any file in
a given directory by setting the limit of versions to 1 version 
for that file (or any file in that directory).  This is effectively 
the versioning semantics offered by UNIX systems.  When implemented 
in this way, file versioning is a superset of the the capabilities 
offered by not having file versioning.

Please, let's not get into a list of VMS's faults, I know them well.
File versioning doesn't happen to be one of them.

-Jordan Henderson
jordan@neosoft.com