Re: DAV:checked-out

On Fri, Oct 06, 2000 at 03:42:44PM -0400, Boris Bokowski/OTT/OTI wrote:
> Woah. Where did that come from? Multiple checkouts of a version selector
> were something that I had specifically requested a couple months ago 
> during
> a review. The answer at that time, IIRC, was "sure, it is done like <so>"
> 
> <boris> The change was made because in the old spec, servers that 
> supported workspaces would be confusing for clients because they replaced
> version selectors on checkout whereas other servers created working
> resources at a new URL. </boris>

But then the second client to check the thing out would be attemping to
check out a WORKING resource. That can fail without demanding this whole
"single checkout" mechanism.

> The scenario is:
> 
>   - Joe creates and activity, checkouts out /foo into that activity, and
>     begins updating it.
>   - Jane does likewise.
>   - One or both merge the activity
> 
> <boris> I can see two possibilities for mapping this scenario to deltaV:
>  In the first possibility, which does not use workspaces (or just one),

I'm not using workspaces, and don't plan to. They aren't needed in my
scenario, as working resources at arbitrary URLs are quite acceptable.

>  both Joe and Jane check out /foo using 
>    <DAV:checkout><DAV:target/></DAV:checkout>
>  which creates a working resource at a server-generated URL. The merge 
>  takes care of setting the target of the version selector at /foo. Note
>  that the only difference to the way it was spec'd before is that the
>  version selector's target is not updated when you check in a working
>  resource. But this probably is what you want anyway, since you use
>  activities and merging to update the shared state (and not the check in
>  operation).

This would appear to work since a version resource can have multiple hrefs
in its DAV:checkout-set property.

>  The second possibility is to use three workspaces, a common one, and a 
>  private one for each developer. A checkout, this time without the
>  <DAV:target/>, only affects the private workspace, and you can use
>  activities and merge to update the shared state in the common workspace.
> </boris>

I'm using activities to operate as a Change Set. Now you're also saying that
I must create/destroy a Workspace, too. No way. DeltaV is just broken if I
must do something like:

    MKWORKSPACE
    MKACTIVITY
    CHECKOUT /foo
    PUT /foo
    MERGE /act/123
    DELETE /act/123
    DELETE /ws/123

We're talking a very transitory operation, and building up a workspace for
that isn't right. I'm also not a fan of workspaces to begin with (I don't
like mutating resource types in place).

-------

In John Vasta's email, he said the DAV:checked-out property on the version
selector could be used to diff the working resource against what was checked
out. That is the wrong approach. The DAV:checked-out should be on the
WORKING resource, not the version selector. That is the right place for it,
and it provides exactly the same value. If you are using workspaces, then
the (in-place) working resource will have that property.

-------

DAV:checked-out on a version selector is not right. It should be on a
version resource and on a working resource.

I should be able to multiply-checkout a version selector, and have it imply
the target for checkout each time.


Oh. Geez... and I just saw in the spec. DAV:target *DISAPPEARS* from the
version selector when it gets checked out?

No. No. No. No. <repeat>

If somebody goes and checks out a version selector, then all the clients
will now need to read *two* properties to try and reach the target version
resource? No way. What if I'm trying to do a property report and use
DAV:target to link over to the version resources to fetch their data? Oops.
That doesn't work since DAV:target doesn't exist any more on some of the
version selectors.

Gah.


PROPOSAL:

  DAV:target is always defined on a Version Selector
  Working Resources have a DAV:checked-out property
  Version Selectors never have a DAV:checked-out property
  Version Resources retain their DAV:checkout-set, but drop the bit about
      version selectors having a DAV:checked-out property
  CHECKOUT does not manipulate the Version Selector
  Put the language back in that says a CHECKOUT on a Version Selector
      replaces it with a Working Resource (which seems to be part of what is
      happening here)

I think that's about it.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 6 October 2000 17:41:42 UTC