Re: Simplifying CHECKOUT behavior for core versioning clients

On Fri, Dec 01, 2000 at 12:23:38AM -0500, Geoffrey M. Clemm wrote:
>...
> 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).

This is a good way to distinguish these. Cool.

[ and yes... I still owe some responses to the messages from last week
  regarding checking out collection versions and what that means... ]

> I believe we can address this issue by making branching an optional
> feature (i.e. move it from core to optional).

This is fine with me.

> Since "merging" is an
> optional feature, and since branching is of limited value without
> merging,

Not so sure that I agree with this, but that disagreement doesn't bother me
at all :-)

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

As Boris has pointed out, parallel development does not imply branching. It
really implies "making changes in private." This is an important
distinction.

That said: it is also reasonable to assume there are versioning systems that
do not provide a way to keep changes private until "formal check-in." (a
fileserver kind of operates this way)

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

I'm not sure that I followed this logic.

Without branching, there is no multiple checkout. [typically; you might
still allow it, but only one person can check-in; the other will need to
undo/cancel their checkout]

The second statement about version selectors doesn't seem to follow from the
multiple checkout thing.

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

This is dangerous behavior to tell clients to use. For a server that *wants*
private changes to be possible, and wants the client to use the working
resource, then clients using the above behavior will choke. If they do a
CHECKOUT on a v-selector, then do a PUT to it (even if the server gave them
a w-resource), then the PUT will fail.

If the server returns a working resource, the client must use it.

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

I like the distinction of server types. However, I'm not sure that we can
make a simplification as you suggest (e.g. only use v-selectors).

Moving branching to optional is fine/good, however.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 1 December 2000 20:38:50 UTC