Re: Versioning Conf Call 5/8/2000 - Unreserved checkout flag for activities

From: Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Date: Mon, May 15 2000

  • 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