Re: Initializing a new workspace using an RSR

From: jamsden@us.ibm.com
Date: Tue, Apr 11 2000

  • Next message: jamsden@us.ibm.com: "Unversioned members of versioned collections"

    From: jamsden@us.ibm.com
    To: ietf-dav-versioning@w3.org
    Message-ID: <852568BE.0048FBD8.00@d54mta03.raleigh.ibm.com>
    Date: Tue, 11 Apr 2000 09:17:06 -0400
    Subject: Re: Initializing a new workspace using an RSR
    
    
    
    
    
    I like it.
    I would have the RSR be a property of the workspace though, and allow it to
    be edited to reflect new contents of the workspace. So I think we need two
    concepts for a workspace - the versioned resources that specify its scope
    or members, and the RSR which picks the revision. Static workspaces require
    a refresh while dynamic workspaces do incremental updates and refresh,
    although possible, is not needed.
    |------------------------+------------------------>
    |                        |   Henry Harbury        |
    |                        |   <Henry.Harbury@merant|
    |                        |   .com>                |
    |                        |   Sent by:             |
    |                        |   ietf-dav-versioning-r|
    |                        |   equest@w3.org        |
    |                        |                        |
    |                        |   04/10/2000 04:09 PM  |
    |                        |                        |
    |------------------------+------------------------>
      >------------------------|
      |                        |
      |           To:          |
      |   ietf-dav-versioning@w|
      |   3.org                |
      |           cc:          |
      |           Subject:     |
      |   Initializing a new   |
      |   workspace using an   |
      |   RSR                  |
      >------------------------|
    
    
    
    
    
    
    
    
    
    Assuming static workspace behavior (draft 4.2), I think it would be useful
    to use the old concept of an RSR to (optionally) initially populate a new
    workspace when created.
    
    The RSR could be passed in the header of a MKWORKSPACE method.  The
    workspace would then be populated using this RSR, and the RSR could then
    persist as a protected property of the workspace for later use/reference.
    The workspace would then follow the "static" behavior for revision
    selection (using the SET-DEFAULT-REVISION method associated with that
    workspace).  This would greatly simplify the use-case for creating
    workspaces on-the-fly based on labels/activities/baselines/etc.  It might
    be useful to define a difference report of the current selection of a
    static workspace and what the originating RSR would select at the time of
    the report.  This would give the client a way to "remember" what that
    particular workspace was intended for (based on its initialization RSR),
    and what is currently different between  that RSR and that active
    workspace's selection.
    
    Comments?
    -- Henry.