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

Simplifying CHECKOUT behavior for core versioning clients

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 1 Dec 2000 00:23:38 -0500 (EST)
Message-Id: <200012010523.AAA06132@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

Note: The following message does *not* propose any changes to either the
semantics or the marshalling of the versioning protocol, but rather
just suggests making some current core semantics optional.

Currently, a core versioning client must check to see whether the
server supports version selector or version checkout, before it can
operate against a server.  This is because there are some servers that
only support "server side workspace" semantics for parallel
development (i.e. only support checking out a version selector), and
others only support "client side workspace" semantics for parallel
development (i.e. only support checking out a version).

I believe we can address this issue by making branching an optional
feature (i.e. move it from core to optional).  Since "merging" is an
optional feature, and since branching is of limited value without
merging, it probably makes more sense make branch/merge a unified
optional feature, instead of the way it is now, where branch support
is required but merge support is optional.

I am periodically asked why core versioning requires support for
branching (parallel development) when many useful versioning servers
(primarily for document management) only support linear versioning.
This is another motivation to make support for parallel development

If branching is not in core, then there is no need for a resource to
be checked out twice at the same time.  This means that neither
workspaces nor working resources are required, and just the ability to
check-out and check-in a version selector is sufficient.  Note that a
server that is "working resource" based can easily implement this
behavior by associating a working resource with the version selector
while it is "checked out", and direct all operations on the version
selector to this working resource.

We would then define two alternative forms of optional parallel
development, "client side workspaces" (with working resources) and
"server side workspaces" (with working resources).


Received on Friday, 1 December 2000 00:24:21 UTC

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