- From: John Hall <johnhall@evergo.net>
- Date: Thu, 14 Jun 2001 15:55:47 -0700
- To: "'Clemm, Geoff'" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
I have a non-forking server and I will not allow people to check out a prior version, which seems to be allowed in the spec. I'm willing to refuse to allow a CHECKIN on the working copy and require it be issued on the VCR. But a CHECKIN that doesn't 'check the file in' violates the expectations of every user of every source control system I've ever seen. -----Original Message----- From: ietf-dav-versioning-request@w3.org [mailto:ietf-dav-versioning-request@w3.org] On Behalf Of Clemm, Geoff A working resource can be created by checking out an arbitrary version, so in general, it is not associated with any VCR. So you do need to support either the update feature or the merge feature if you support the working resource feature (that is why the client-side workspace package contains the update feature. Cheers, Geoff -----Original Message----- From: John Hall [mailto:johnhall@evergo.net] Sent: Thursday, June 14, 2001 3:15 PM To: 'Clemm, Geoff'; ietf-dav-versioning@w3.org Subject: Question on Checking (of Working Resource vs. VCR): is this right? My user performs a CHECKOUT, PUT, and CHECKIN. He wants the contents to change, and he wants a new version. I'm using working resources. To get this behavior, the user must: 1) CHECKOUT the VCR. 2) PUT on the working copy identified by the Location URL in the CHECKOUT response. 3) CHECKIN the VCR. It appears that if they do a CHECKIN on the working copy, they will not get what they expect. 9.4 indicates that they create a 'version' but that the VCR doesn't know about it. Since I don't support UPDATE or MERGE I seem to have two options. Fail the CHECKIN on a working copy or treat it as a CHECKIN on the VCR silently.
Received on Thursday, 14 June 2001 18:55:49 UTC