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

> 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.

What it seems you're trying to do is make the server models for mutable
and immutable versioning interoperate.  However, I don't think that's
necessary.  For interoperability, we only need *clients* to be able to
understand what the server is doing.  We already know that clients will
have to be able to find out if servers support mutability or not; if
they do, it's not that hard for the client to have a slightly different
model of what's going on.  Any client developers want to chime in here?

> 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.

In what way is the "mutable version option" incompatible with merging,
baselines, or activities?

>    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.

Right, but what I'm saying is that as long as the client knows we're
breaking the semantic, then the client knows how to behave.

Normally I wouldn't propose two such divergent server models, but in
this case I'm coming to believe that the document versioning model is
almost incompatible with the code versioning model.  They might not be
able to coexist on the same server, or at least in the same namespace.

> 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.

That's right.  It's too bad.  How else do you want to deal with
auto-save, though?

> 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.

No.  If the client can count on being able to find out whether something
is true, then it doesn't have to have any kind of assumptions.  This
just requires discovery of whether "version URLs reusable" is true or
false.

> 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.

Right, but that's because baselines/activities/merges are all code
versioning options, therefore they all fit the code versioning model.  I
think the document versioning model is sufficiently different that it
may not be completely compatible with code versioning.

Tough problem, I know :)

lisa

Received on Friday, 5 January 2001 20:00:42 UTC