pathnames

[Chris Bitmead uid]

>> If you want the latest version you should have to ask the
>> registry. (Please-give-me-a-reference-to-the-latest-version-of
>> "Treasure Island"). The latest version is an abstract notion, and
>> it is not appropriate to use a direct reference.
>> 
>> Destructive anything, is in general a bad idea.
>
>Right!
>
>My riginal idea for a version system, which started this little threadlet,
>to save everyone from trawling back through the archives - was that
>a single thing representing all version of the same object was used
>to identify it, unlike the UNIX approach, where many seperate files 
>are used to track the same object through it's lifespan.
>
>Eg, we have "/Public/Hello!", which on it's own by default
>refers to the most recent version.
>
>OTOH, since "/Public/Hello!" really refers to all the versions,
>which are uniquely and nondestructively numbered from 1 upwards,
>so I can ask for them individually. Going back to my favourite
>syntax, we'd have:
>
>(define my-book (make-path *internet* "abwillms.demon.co.uk" 'Public 'Book))
>
>(let
>     (book (open my-book :version 5))
>     ...

I think if you think through all the issues you might find that a
generic magic system like this will run into a lot of problems.

Let me put forward a scenario. Let's say, I have a friend call Zaphod
who writes poems. I like to store a collection of my favourite poems
written by Zaphod. Zaphod changes his poems, now and then, but
sometimes he mucks them up, IMHO, so I like to store specific versions
of his poems for my reading pleasure.

Ok, so I guess under your system there is a container for each poem,
and that container contains different versions of a poem.

Since I like particular versions of poems, I choose to have my
favourite-zaphod-poems pointing not to the collection of versions but
to specific versions.

(define favourite-zaphod-poems 
    (list (open zaphods-poems "Ode-to-green-jelly" :version 4)
          (open zaphods-poems "Stuntship" :version 2)))


One day I call Zaphod over to my terminal. I say to him "Wouldn't your
ode to jelly be much improved if you said something about red jelly
too?", as I point at his version 4 jelly ode. Zaphod agrees excitedly,
and adds a new stanza there and then and saves the new version of the
poem.

Now what does the super-duper magical version system do?

My ode-to-green-jelly object is not one of these magic container
objects that stores multiple versions, so it can't add a version to
that.

If each object has a magic link back to its version container, then it
could become a version 27 ode-to-green-jelly in zaphod's original
container. It's debatable if that's correct anyway. Does Zaphod really
want red jelly in his latest version of the ode, or did he only put
that stanza in to humour me? In any case I probably don't have
permission to alter his master container.

Even if he does want that to be the latest and greatest, (presumably
abandoning all this improvments between V4 and V26), my
favourite-zaphod-poems will still be left pointing at V4 instead of my
new favourite V27, because there is nothing magical to know that what
I really wanted was my list to point to the new V27. I might in fact
store the new version in a different variable (or I might not)...
ode-to-red-and-green-jelly. Now how does the system know if that is
another version of the green jelly, or a new red-green entity? Zaphod
might like it to be the latest in his green jelly series, or he might
have preferred to fork a new series of red-green jelly poems.

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.

>Whereas without the optional version argument, it returns the newest.
>A version given as a symbol, "newest", would also have this effect.