pathnames

[BRIAN SPILSBURY]

ABW> > I'm not sure why you want this extra lowlevelness, wouldn't a transluscent
ABW> > versioning container do the trick?
ABW> > 
ABW> > Just forwards all method calls onto the most recent version, unless
ABW> > you use its versioning-api?
ABW> > 
ABW> > Maybe I've missed the point.
ABW> 
ABW> That's what I'm aiming for now.
ABW> 
ABW> A versioning container should be optional. It's defined entirely
ABW> in terms of the underlying system. If it is used to wrap a
ABW> "file" like a document or similar, rather than something conforming
ABW> to the "group of files" protocol (directory/folder/archive file),
ABW> it acts much as I have described.

Certain it should be optional, but um, why do we want to define it
at a lower level? We could write this in CLOS quite happily, although
we'd have to use no-applicable-method or use a condition to trap it.

ABW> If it wraps a group of files, then it tracks modifications to it's children
ABW> by making a new version of the group, too.
ABW> 
ABW> So Treasure Island would be put in one version controller as a group of
ABW> files. Ugdating a subfile would cause version 2 of the subfile to be created,
ABW> and a new version of the directory that contains the newest versions of
ABW> everything.

Well, if you look at the cltl2 path-name support it already has versioning
that seems rather similar to that.

But it seems awfully high level and irritating to go at a low level,
I would find such versioning incredibly irritating in most cases.

Brian