Re: Simplifying CHECKOUT behavior for core versioning clients

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

Note that both "server side private workspaces" and "client side workspace
semantics" allow users to make changes that are not seen by other users.
If core clients check out in place, their changes will be seen by other
users. This is true even in the case of simple linear histories, so the
following scenario would not be supported: update both contents and
properties on a privately checked out resource, followed by a CHECKIN
and a SET-TARGET which updates content and properties atomically for
other users.

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

The MERGE method is optional, but a client can merge "by hand" using
only core features (merging content and properties as appropriate,
on a checked out resource, and then setting the DAV:predecessor-set
property before the CHECKIN).

> 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
> optional.
> 
> If branching is not in core, then there is no need for a resource to
> be checked out twice at the same time.

I could agree on this, but what about the need for checking out a
resource privately (see above)?

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

On a "working resource" based server, version selectors would never
be checked out, and it would always be possible to SET-TARGET them
(or MERGE). This is no longer true in the model you propose.

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

Boris.

Received on Friday, 1 December 2000 11:53:42 UTC