- From: Eric Sedlar <eric.sedlar@oracle.com>
- Date: Fri, 9 Feb 2001 12:51:44 -0800
- To: <ietf-dav-versioning@w3.org>
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