Re: Mutable Versions (was: re-use of version URL's)

   From: "Lisa Dusseault" <lisa@xythos.com>

   What you propose makes it impossible for a core-versioning server to
   implement mutable versioning: the server (and clients!) would have to
   implement labels as well.

A server always had to implement more than core versioning in order to
support mutable versioning (mutable versioning was always an option,
and one that many, if not most, versioning servers were not going to
implement).  I agree that there are simpler ways to support mutable
versioning than labels, but I do not believe that there is a simpler
*interoperable* way of supporting mutable versioning.

The difference between the "mutable version option" and the "label
option" is that "labeling" is compatible with the other versioning
functionality, therefore mutable versioning via labels adds to
interoperability, while most of the other options (merging, baselines,
activities) are incompatible with the current "mutable version
option", and therefore the current form of the mutable version option
seriously harms interoperability.

   A simpler proposal would be just to have an "ismutable" flag that could
   be queried on any resource.  A core-versioning server could treat a
   CHECKOUT as creating a new version, whereas a PUT without a CHECKOUT
   would alter the current version.

And just as with "re-using version URL's", the result is breaking an
key semantic that the versioning protocol provides to clients, namely
that the version URL reliably identifies a specific state of a
resource.

So you are being consistent in supporting re-use of version URL's
and mutable versions, but all the arguments for not re-using version
URL's apply to not allowing a version to be changed.

   I would support having an "ismutable" flag in CORE, because it is
   trivial for a server that does not support mutable versions to set this
   always to "false", and vice versa of course.

This effectively forces every client to be a mutable versioning client,
or to refuse to talk to a mutable versioning server.  Currently, there
are a large number of things a client can do if it can count on a
version-URL always reflecting the same content and dead properties.
It can cache that information on the client, knowing that it is always
up to date.  It can request "delta" content updates from the server,
by passing in the "version URL" it currently knows about, and having
the server just send back the diff between that version and the current
content on the server.  It can merge, it can save those URL's in dead
properties, and all the other points raised on this thread.

   I've been doing some thinking about his, and I'm about to construct a
   mail that outlines how mutability is absolutely necessary in some
   situations, and how human-readable version URLs help out in these
   situations.  Wait for it... ;)

Will do, but remember, the whole point of a protocol is to provide
interoperability.  If you can't count on something being true, an
interoperable client just has to assume it's not true.  If you can't
count on a version URL identifying the same content and dead properties,
then you just can't do any of those things that depend on being able
to count on that.

Notice that none of the other versioning options have this
characteristic of breaking things that used to work.  If you can
version collections, that does not break anything you could count on
from versioning leaf resources.  If you can baseline collections, that
does not break anything that you could count on without baselining.

So that's why the introduction states that "these options have been
defined to be orthogonal".  Unfortunately, this is very much not true
about the current mutable versioning option, which if supported
seriously breaks a key semantic (some would argue, *the* key semantic)
of the core versioning protocol.

Cheers,
Geoff

Received on Friday, 5 January 2001 13:26:53 UTC