- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 4 Jan 2001 23:22:10 -0500 (EST)
- 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 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. > 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 server. 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. Cheers, Geoff
Received on Thursday, 4 January 2001 23:22:59 UTC