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

RE: ... By the way ...

From: Lisa Dusseault <lisa@xythos.com>
Date: Wed, 8 Aug 2001 05:03:57 -0700
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <HPELJFCBPHIPBEJDHKGKOEPCCKAA.lisa@xythos.com>
So in our discussion today at the IETF, we realized that the version-history
report can also be used to see all values of <checkout-set> and
<checkout-fork> for a single version-history.   This means that
expand-history report isn't needed to support this, only version-history
report which is already required.

lisa

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> Sent: Sunday, July 15, 2001 7:35 PM
> To: ietf-dav-versioning@w3.org
> Subject: RE: ... By the way ...
>
>
>
>    From: John Hall [mailto:johnhall@evergo.net]
>
>    As I understand it, there is no way for a client to tell that a
>    working resource has been created.
>
>    VCR checked in, no working resources have been created.  Server
>    doesn't allow forking.  Server supports WORKING-RESOURCE and
>    CHECKOUT-INPLACE.
>
>    ClientA: CHECKOUT <apply-to-version> VCR.
>    => creates working resource and leaves VCR untouched.
>
>    ClientB: Since VCR is untouched, it is impossible to detect that
>    CLientA has performed their operation.  Therefore:
>
>    CHECKOUT VCR
>    => 409 Conflict
>    <checkout-of-checked-out-version-is-forbidden>
>
>    Is there some way I'm missing that Client B could have seen this
>    one coming?
>
> Use the DAV:expand-property report to ask for the checkout-set and
> checkout-fork properties of the checked-in version, i.e.:
>
> <D:expand-property xmlns:D="DAV:">
>  <D:property name="checked-in">
>    <D:property name="checkout-set"/>
>    <D:property name="checkout-fork"/>
>  </D:property>
> </D:expand-property>
>
> If the checkout-set is non-empty and checkout-fork is forbidden,
> you know the checkout will fail.
>
>    Currently, I don't support forking so only 1 checkout (INPLACE or
>    WORKING) is allowed.  But if I did support multiple checkouts, I'd
>    still keep a count so I could tell Client B, that forking was
>    'discouraged', for example.
>
> Yes, if the checkout-fork is discouraged, that would be something
> you'd want to warn them about (and if they said "do it anyway", you
> would know to include the DAV:fork-ok flag with the CHECKOUT).
>
>    Are people implementing this without tracking the count of working
>    resources created off the versions of a VCR?
>
> The list of checkouts is important, which is why the server is
> required to maintain DAV:checkout-set.
>
> Cheers,
> Geoff
Received on Thursday, 9 August 2001 06:52:48 GMT

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