Date: Mon, 15 May 2000 11:56:37 -0400 (EDT) Message-Id: <200005151556.LAA01558@tantalum.atria.com> From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org Subject: Re: Versioning Conf Call 5/8/2000 - Unreserved checkout flag for activities From: "Jim Doubek" <jdoubek@macromedia.com> During the last few minutes of today's conf call, a number of issues were raised about the 'unreserved' checkout flag. COnferees at the time were Tim Ellison, Jim W, Henry Harbury and myself. What follows is my interpretation, rather than minutes or notes, so others should feel free to correct where appropriate. As written, the 'unreserved' flag is is on the second checkout, not the first for a revision. This doesn't seem to match the term 'reserved' which would infer that the reservation is done by the first checkout, affecting all subsequent. How does one prevent a latecomer from checking out the second working resource? Yes, there should be a DAV:unreserved (or DAV:reserved) property on a working resource, so that whether or not there is a reserved checkout is remembered. Several people raised the problems having multiple checkouts in a single branch introduces in doing a merge. Since an activity can contain only linear revisions, one cannot checkin both working resources before the merge, so how is this done? The client would have to checkout the current tip of that activity, merge the contents of the previous checkout into that new working resource, uncheckout the old working resource, and then checkin the new working resource. It was pointed out that an activity points to revisions, not working resources. How does an activity keep track of working resources that are checked out in its behalf. Currently it doesn't, but given a particular versioned resource, you can check if any of the working resources of that versioned resource are checked out into that activity (which is all you need for the reserved/unreserved behavior). This actually is a bigger issue, since many ui's will want to show all checkouts (work in progress) for an activity. Note that because of the next point, one can not get this info by going through workspaces. Additionally, working resources for an activity may in fact be specified by via means other than workspace, it seems. I'm not sure that this is all that common of a query, but if it is, we could consider how to support it, but we currently have no "workspace independent" URL for identifying a versioned resource. Activities backpoints to workspaces that have it as current activity (DAV:workspace-set) but not to those containing working resources. The current activity for the workspces may have changed since checkout, so these two sets of workspaces are not necessarily the same. Since revisions are added to the activity in checkin, there doesn't seem to be a list of all the 'work in progress' for an activity. It was observed that there is no way to add revisions or resources to an activity except via checkin. <jimd> In later looking at the properties of revision and working resource, it appears this can be done by setting the DAV:activity of the resource or revision, correct? </jimd> Yes, the DAV:activity property of a revision is currently not marked as being "protected". That is probably a mistake, though, so if we wanted a way to "update" the DAV:activity of a revision, I probably would vote to introduce a method to do so. DAV:activity is single valued for revisions. There is no way to denote that a single checkin relates to multiple activities, which is often the case. The problem with multiple activities associated with a single revision is that its semantics are unclear, i.e. when you merge that activity into a workspace, do you merge a revision if *any* of its activities are that activity, or only if you are trying to merge *all* the activity annotations into the workspace. Cheers, Geoff