W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: Working collections

From: Greg Stein <gstein@lyra.org>
Date: Fri, 17 Nov 2000 12:28:20 -0800
To: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20001117122820.K21426@lyra.org>
On Fri, Nov 17, 2000 at 03:00:35PM -0500, Geoffrey M. Clemm wrote:
>    So when you check out a versioned collection what can you do
>    with the resulting working collection?
> Working on a checked out version selector for a collection is well
> defined, so I assume you mean "when you check out a collection
> version, what can you do with the resulting working collection"?
> You are right that this is not defined, and does not follow from the
> semantics of checked-out version selectors, so this needs to be fixed.
> My first choice would be your subsequent answer, i.e. that "you can
> only check out a collection version selector, and not a collection
> version".  Greg doesn't like that answer, so it's probably worth exploring
> what a working collection might be (although I haven't given up hope
> in trying to get Greg to just use workspaces and checked out version
> selectors :-).

Why would a checked-out version selector (of a member or a collection) ever
be any different from a working resource? What would be the justification
for such a difference?

Doing a check-out in place does not work well for me. I want to construct an
activity, check out a bunch of things w.r.t. that activity, make the
changes, then merge the activity in one fell swoop. That model works great,
and I don't see any incentive/benefit to using a different model.
[ I will admit to not reading the latest incarnation of workspaces, but it
  still seems moot if the activity model and working resources satisifies my
  problems ]

>    Are you constrained to creating members that bind to histories only?
> If we allow it working collections, then being constrained to creating
> members that bind only to histories makes sense.

If I do a PUT into a working collection, then this constraint would be
satisfied at MERGE time. Anything PUT into the collection is automatically
versioned, so the updated collection version would refer to the version
history of the new resource.

>    When the server sees a URL to a working collection, say of the form
>    http://repo.webdav.org/vr/9/wr/1/foo it can 'know' about the form of these
>    URLs to determine that everything up to 'foo' is the URL to the working
>    collection and 'foo' is the member of that collection, but there would be
>    (typically) no relationship between that URL and the URL of the history
>    resource that 'foo' is currently bound to; so it would not be possible to
>    slash-through 'foo' to reach other resources.
> Correct, which is why I find working collections of negligible value
> (compared to checked-out collection version selectors, which you can
> slash-through).

In the model that I'm going to use, I don't need to "slash-through" the
working collection. I just need it to establish a spot where I can create
new members/sub-collections. If I want to reach an existing child resource,
then I'll go through version selectors (to their versions, which I CHECKOUT,
and then to their working resources).

I think the point here is that I'm working in a transactional / change set
model here. I get a bunch of working resources, change them, then check them
in in one fell swoop. Navigation and management of checked out resources is
minimal and short-lived. Give me a working resource, I'll tweak in, then
merge it back in (possibly with other changes).


Greg Stein, http://www.lyra.org/
Received on Friday, 17 November 2000 15:30:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:45 UTC