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

Re: CHECKOUT of a baseline

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Fri, 5 Jan 2001 08:39:43 -0500 (EST)
Message-Id: <200101051339.IAA29597@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

   From: Greg Stein <gstein@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:
   > 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.

Suppose there are 10,000 resources in your baseline-controlled
collection.  You just want to change the version of one of them.  It's
a bit painful to download the entire all 10,000 DAV:href's in the
DAV:version-set property, so you'd like a "replace just this version"
method.  And then maybe a "delete just this version" method.  And
while we're there, an "add just this version".  Subversion wouldn't
want this, but others have asked for it, which is why we have an
UPDATE method, which you can point at a version-controlled resource
and do this incremental update (the add and delete are handled by
VERSION-CONTROL and DELETE).  I just don't want to have a parallel
UPDATE-BASELINE-VERSION-SET method that is just a different way of
doing what UPDATE/VERSION-CONTROL/DELETE does already.

But happily, you don't need it, so we don't have to go there (:-).

Received on Friday, 5 January 2001 08:40:32 UTC

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