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

Re: CHECKOUT of a baseline

From: Greg Stein <gstein@lyra.org>
Date: Fri, 5 Jan 2001 02:17:56 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20010105021756.P17220@lyra.org>
Per the other note (with the slightly modified semantics), I'm totally fine
with this change. I just have a few nits to close up below.

On Thu, Jan 04, 2001 at 11:22:10PM -0500, Geoffrey M. Clemm wrote:
>...
>    From: Greg Stein <gstein@lyra.org>
> 
>    On Thu, Jan 04, 2001 at 03:19:43PM -0500, Geoffrey M. Clemm wrote:
>    >    From: Greg Stein <gstein@lyra.org>
>    > 
>    >    Just verifying an assumption...
>    > 
>    >    A baseline is a version resource, which would suggest that I can do a
>    >    CHECKOUT on that resource, modify it, then check it back in.
>    > 
>    > Well, you could, but it wouldn't do you much good because because you
>    > wouldn't be able to modify the DAV:version-set (it does not appear
>    > on a working resource).
>...
>    Why not? :-) Below, you state that the protected status is based on what
>    resource the property appears on. Why couldn't we say the version-set
>    property appears on a baseline's working resource as an unprotected
>    property?
> 
> We could do that, but I don't think we have to (i.e. we can just let
> MERGE do its magic, and have the DAV:version-set be based on the
> DAV:checked-in versions of the baselined collection, as usual.

While I don't need the modify-DAV:version-set behavior, I think it would be
more consistent to allow somebody to modify a baseline in this way. You
could call me "neutral" on this, tending towards "add it for consistency."

>...
> I believe the real question is: are there multiple ways of defining
> the DAV:version-set of a baseline, or a single uniform way?  My
> concern with having different ways of defining the DAV:version-set is
> that a server is likely to support just one or the other, which would
> mean clients would either have to try it each way to work against both
> kinds of server, or a client would only work against one kind of
> server.

I understand. I'll slightly argue that consistency dictates that somebody
could do:

     CHECKOUT /some/baseline
     PROPPATCH version-set=[...]
     CHECKIN /the/working/resource

Just like they can do with any other version resource.

> Since "collections" are the standard WebDAV way of grouping together a
> set of resources, it seems natural to derive a baseline from that
> standard way of grouping resources.  If in addition, we started
> defining ways of directly manipulating the DAV:version-set, we would
> soon be faced with many of the incremental update issues that collections
> currently address.

Incremental update? I'm thinking of a single PROPPATCH. I'm not sure that I
understand your concern here.

> If the solution described in the "summary" gives you what you need,
> we would be able to stick with the "unified baseline creation model".

It does; I'm just thinking about other users. For example, I won't use
CHECKIN on an activity, but I think it is an entirely valid concept.

If somebody out there wants to champion it... otherwise, I'm going to guess
that Geoff won't want to add this :-)

>...
> These are some of the reasons why I have always felt it to be
> essential that versioning not depend on locking.  So please forget I
> ever brought up the baseline selector locking suggestion (:-).

Forget what? I don't recall what you're talking about. :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Friday, 5 January 2001 05:18:33 GMT

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