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: Thu, 4 Jan 2001 23:22:10 -0500 (EST)
Message-Id: <200101050422.XAA28975@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

Quick summary: I believe Greg is right.  A "working baseline" is a
better way of marshalling what he wants to do than locking a baseline
selector.  In particular, all we need to do is to specify in the
semantics of MERGE that the order of operations when merging an
activity are:

1 - check-in working resources
2 - merge versions into merge targets
3 - check-in baselines
4 - merge baselines into merge targets

I'll add this clarification to the spec if nobody objects.

More details below:

   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).

My statement above is wrong, because MERGE operation as defined above
gives the server enough information to create the appropriate DAV:version-set.

   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

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.

   > So you have to CHECKOUT a baseline selector, modify it, and then check
   > that back in (the baseline selector uses its baseline-controlled
   > collection to determine what the DAV:version-set will be).

   Hrm. In other words, it only follows the server workspace model; client
   workspace people are out of luck :-)

No, that would not be OK (:-).

   One model says "construct the baseline from what you see in the workspace"
   and the other says "construct the workspace from what you see in the
   baseline". Subversion uses the latter.
   I'd maintain both are valid :-)

The protocol today supports both of these directions, i.e.
"CHECKIN baseline-selector" creates a baseline from a workspace, and
"UPDATE baseline-selector" creates (populates) a workspace from a baseline.

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

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.

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

   >    In my particular case, the CHECKOUT will be part of an activity, the
   >    baseline will *not* be auto-versioned, the checkin will occur as part of
   >    merging an activity, and the modifications that I'm considering is simply a
   >    PROPPATCH.
   > If you want to modify the properties of the baseline, you would need
   > to LOCK the baseline selector before doing the MERGE.  The

   Subversion doesn't support the LOCK method anywhere.   Further, this would
   pose problems during a simultaneous update. Failure to unlock the selector
   properly (client crash, badly-written clients, etc) would pose
   administrative nightmares with clearing the lock periodically (yah, yah, we
   could force a small timeout on the bugger, but that just brings about other
   problems with determining "how long will the MERGE / PROPPATCH take? [over
   this network connection]").

OK, you totally got me on this one (:-).

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 (:-).

   > auto-versioning behavior would keep it checked-out until you released
   > the lock, which gives you time to update the properties (it's probably
   > a good thing to have the lock anyway, to prevent other clients from
   > updating those properties while the baseline selector is checked out).

   Given a working resource for a baseline, I wouldn't be worred about other
   clients modifying the properties.

Yup.  When you're right, you're right (:-).

   And the baseline is constructed as part of the commit process (read: the
   MERGE method rather than the UNLOCK of a baseline selector).

Yes!  Of course!  (Now why didn't I think of that :-).

   Not to mention total lack of support for LOCK/UNLOCK.

Yes and yes again.

   Personally, I see a "wart" in the draft if we can't check out a baseline.
   Right at the beginning of S9.2, it says, "Since a baseline is a version
   resource, ...". To me, that implies I should be able to CHECKOUT the bugger.
   Saying that I /can't/ seems to introduce an artificial disparity.

Well, I never said that you couldn't check out a baseline, just that
it wouldn't do you any good (OK, I was wrong about the second part,
but at least I wasn't introducing an artificial disparity :-).

   I do understand that limiting the dichotomy might be nice, but the baselines
   are just variants of existing things. I say, treat them like the originals.
   Otherwise, you have client-workspace clients using two models: server-based
   for the baselines, and client-based for the rest.

Yes, I agree that it feels more consistent to use working baselines with
client workspaces.  But I'd still like to keep the "baseline is a
snapshot of a collection" concept if at all possible.

   The problem that I'm looking at is with respect to automatically updating
   the DAV:version-set during the MERGE operation. That would require an actual
   spec change to describe the operation.

   My suggestion is to add a bit of text to the Activity CHECKIN stuff to deal
   with baseline working resources. Since MERGE is basically doing an Activity
   CHECKIN, it will just pick up that behavior (plus a small bit about merging
   into a baseline selector).

So would the wording described in the summary be acceptable?  It lets
you check out baselines (as you wanted), and then explains why MERGE'ing
your activity will have the desired result, using the standard "snapshot
of a collection" semantics.

Received on Thursday, 4 January 2001 23:22:59 UTC

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