Re: DeltaV doesn't support a true client workspace

On Fri, Feb 09, 2001 at 05:58:54PM -0800, Fay, Chuck wrote:
>...
> I view retention policy as a workaround or band-aid to the real problem,
> which is not giving core versioning clients an obvious, clean, safe way to
> check in a new version explicitly.  Auto-versioning is great for backward
> compatibility, but it's not real versioning in the classical sense of
> checkout, change, checkin.  LOCK, PUT, UNLOCK is error-prone, in that
> clients will have to know not to do more than one PUT (for servers that
> don't support storage of intermediate state), to avoid the proliferating
> versions trap. With the alternative, i.e., CHECKOUT/CHECKIN methods, it's
> obvious to the developer that you only get to do one CHECKIN call per
> CHECKOUT.  The client just has to check to see if the mutable VCR option is
> supported.  If so, it can do intermediate PUTS; if not, it saves all changes
> for the CHECKIN method.  How can we deny the core versioning client access
> to CHECKOUT/CHECKIN methods?

You are not suggesting anything new. If the client can avoid intermediate
PUTs, with the intent of sending it during the CHECKIN, then the client
can/should just use a single PUT (with or without locking or checkin/out).

There is no reason to add complexity to the core protocol to support a
trivial (the name of the method that delivers the content) change in the
client.

Cheers,
-g

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

Received on Friday, 9 February 2001 21:19:24 UTC