W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Newbie Versioning Question

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Mon, 16 Oct 2000 18:06:03 -0400 (EDT)
Message-Id: <200010162206.SAA26536@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: "Edeen, Eric" <eedeen@pesolutions.com>

   I have (what I hope) is a relatively straight forward question regarding the
   Delta-V versioning model. Does the spec require implementations to support
   version branching, i.e., versions with two or more successors?

We call that "forking" (since we use the term "branch" for a special
kind of activity), but no, a server does not have to support version forking.

An interoperable versioning client SHOULD be prepared to deal with
forking (since it may encounter it), but it can deal with it in as
primitive a way as it wants (something better than "dumping core"
is probably preferable :-).

   Can an
   implementation that supports only linear version still be compliant with the

Yes.  The standard way to expose this restriction is to have the
server set the property DAV:checkout-fork or DAV:checkin-fork on a
version-selector to be DAV:forbidden (one prevents forking on
checkout, the other prevents forking on checkin).

   Does the spec allow an implementation to simply fail a CHECKOUT
   operation on a versioned resource when the target is not the tip in a linear
   version series?


   If so, what would be the appropriate response code and body?

You would return status 403 and in the response body, either:




whichever is appropriate.  This is considered "optional"
functionality, so it appears in the advanced CHECKOUT section.

   I note that earlier versions of the spec contained references to a
   <DAV:branch-ok> element.


   This seems to imply that some consideration was
   given to this question in the past. Am I understanding this correctly? If
   so, what ever became of it?

It's still there (look at advanced CHECKOUT and CHECKIN).
It's in advanced, because this is optional functionality.

Received on Monday, 16 October 2000 18:06:40 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC