Next message: Clemm, Geoff: "Versioning TeleConf Agenda, 5/15/00 (Monday) 2pm-3pm EST"
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