RE: DeltaV doesn't support a true client workspace

The way we handle the version proliferation problem is to keep a maximum
number of the number of autoversioned versions to keep around.  In a
previous product, we had a limit on the number of "unreleased" (in DeltaV
terms, unlabeled and unbaselined) versions to keep around.

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

--Eric

-----Original Message-----
From: ietf-dav-versioning-request@w3.org
[mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Fay, Chuck
Sent: Friday, February 09, 2001 9:10 AM
To: Geoffrey M. Clemm; ietf-dav-versioning@w3.org
Subject: RE: DeltaV doesn't support a true client workspace



> but also allows you to have just one new header, instead of requiring
> a new header for every parameter to CHECKIN.
> 
> So I have two questions:
> 
> Chuck: Does the Autoversion header for PUT get you what you need?

No (see above).  To reiterate briefly, I'm trying to avoid a proliferation
of versions created by auto-versioning.  My server would auto-version only
for versioning-unaware clients.  Versioning-aware clients would CHECKOUT,
GET, do all modifications locally on the client, then CHECKIN with the new
content as the CHECKIN request body.  What could be simpler?  I strongly
urge that this model of use be supported by DeltaV.  Note that my server
would reject any PUTS on a checked-out VCR, because it would not implement
my proposed mutable VCR option.

> Note that to be interoperable with versioning unaware clients,
> you'll have to set DAV:auto-version anyway, so are you sure 
> that existing DAV:auto-version and PUT behavior isn't sufficient?

Yes, because of the problem of proliferating versions.

--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 15:48:00 UTC