RE: DeltaV doesn't support a true client workspace

From Eric Sedlar:
> The way we handle the version proliferation
> problem is to keep a maximum number of the
> number of autoversioned versions to keep
> around.

We thought of this, but discarded it because there is no guarantee that the
right set of versions would be retained.  You could end up with N trivially
different versions, especially due to the proliferation that autosave might
cause, for instance, and lose the versions with significant deltas that
should have been retained.

> In a previous product, we had a limit on
> the number of "unreleased" (in DeltaV
> terms, unlabeled and unbaselined) versions
> to keep around.

That's a great idea if your server supports the label or baseline option.
But it doesn't help servers that don't.  :-(

> When either count is reached, we start
> deleting old versions automatically.

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?

--Chuck Fay 
FileNET Corporation, 3565 Harbor Blvd., Costa Mesa, CA 92626 
phone:  (714) 327-3513, fax:  (714) 327-5076, email:  cfay@filenet.com

Received on Friday, 9 February 2001 21:03:41 UTC