- From: Tim Ellison <tim@peir.com>
- Date: Thu, 13 Sep 2001 09:40:11 +0100
- To: "DeltaV" <ietf-dav-versioning@w3.org>
> -----Original Message----- > From: ietf-dav-versioning-request@w3.org > [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff > Sent: 12 September 2001 21:43 > To: ietf-dav-versioning@w3.org > Subject: RE: Locking > > > From: John Hall [mailto:johnhall@xythos.com] > > ... > Therefore, I see no reason why a VHR should be locked > independently of a > VCR. Either the operation is moot, or (in the case of guidance we have > received on global properties) the proper lock is on the VCR not the > VHR. > > I agree that being able to lock a VHR is of neglibible value. > Someone might decide to implement global properties by placing > them on the VHR, in which case being able to lock a VHR would > be of value to that client, but not a very compelling use case > for me. Locking a version history resource will prevent all clients from creating a new version in that history (e.g., by checking in a version-controlled resource or working resource, or using the VERSION-CONTROL method). When locked the history's DAV:version-set cannot be modified thus preventing these operations. Not sure when that would be useful though<g> Tim
Received on Thursday, 13 September 2001 04:40:14 UTC