W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > July to September 2001

Checked out vs checked-in

From: Lisa Dusseault <lisa@xythos.com>
Date: Tue, 14 Aug 2001 10:43:11 -0700
To: "DeltaV" <ietf-dav-versioning@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKOECPCLAA.lisa@xythos.com>

I was answering some questions about the checked-in and checked-out
properties, and how they can exist, or not...  It required careful rereading
of several related but distant sections of the draft.  I believe I corrected
some of my own misapprehensions and those of the person asking questions
about DeltaV.  I ended up figuring that examples were the best way to
illustrate my understanding of these properties.

Case 1: neither property exists

This case is definitely possible when the resource isn't under version
control.  However, is it possible to see this state when the resource is
under version control?  I think not.  Is this a good way for clients to see
if a resource is under version control?  Is it preferable to use
supported-method-set or this?  It's an important question, because it may
mean that supported-method-set is not a required property for simple
document versioning (DeltaV subset).

Case 2: checked-in exists
Eg:
<D:checked-in><D:href>http://server.com/_foo.doc_v8</D:href></D:checked-in>

Here, the VCR is reflecting the content and dead properties of a version in
its version history.  It is checked in, and it is not checked out in-place.
There may however exist working resources that are the result of checking
out past versions of this resource.  E.g. if version _foo.doc_v5 is checked
out to a working resource, this fact wouldn't be reflected in the checked-in
or checked-out properties.  We've reviewed this behaviour in previous email
conversations, where we discussed how a client could find out if any check
outs existed -- they must look for the checkout-set property on all versions
in the version history, as well as the checked-out property on the VCR.

Case 3: checked-out exists
Eg:
<D:checked-out><D:href>http://server.com/_foo.doc_v8</D:href></D:checked-out
>

Now the VCR is checked-out, and the value of the property indicates what
version was checked out.  Further, this indicates that the resource is
checked out in-place.  That's because if there was a checkout to a working
resource, that would be indicated in properties on the version resource, not
properties on the VCR.  There may also exist working resources that are the
result of checking out previous versions, in addition to the in-place
checkout.

Case 4: checked-out and checked-in both exist -- Impossible

This case should be impossible because of the text in the draft, section
1.3: "A resource under version control is either in a "checked-in" or
"checked-out" state, and the version control constraints apply only while
the resource is in the checked-in state."

This text, however, is very misleading.  I think the misdirection comes from
the fact that the phrase "check out" is used both for in-place checkouts and
for working resources.  It would be more accurate to say:

"A resource under version control is either in a checked-in state or in a
checked-out in-place state.  It may also have any number of working
resources resulting from "checking out" older versions to working resources,
regardless of whether it is in the checked-in state or in the checked-out
in-place state".

Another broader fix to the document would be to reserve the words "check
out" and "checked-out" to the in-place checkout.  Creation of a working
resource could be indicated by different language that does not conflict.

Please confirm my understanding of this and clarify the draft.

Lisa
Received on Tuesday, 14 August 2001 13:43:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:42 GMT