- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Mon, 16 Oct 2000 18:06:03 -0400 (EDT)
- 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 standard? 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? Yes. If so, what would be the appropriate response code and body? You would return status 403 and in the response body, either: <DAV:checkout-of-version-with-descendant-is-forbidden/> or <DAV:checkout-of-checked-out-version-is-forbidden/> 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. Yes. 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. Cheers, Geoff
Received on Monday, 16 October 2000 18:06:40 UTC