proposed versioning usage scenario for client-managed checkouts

From: Chris Kaler (ckaler@Exchange.Microsoft.com)
Date: Mon, Jan 10 2000

  • Next message: jamsden@us.ibm.com: "Re: Baselines vs. labels"

    Message-ID: <FD7A762E588AD211A7BC00805FFEA54B08A0B67C@HYDRANT>
    From: Chris Kaler <ckaler@Exchange.Microsoft.com>
    To: ietf-dav-versioning@w3.org
    Date: Mon, 10 Jan 2000 01:02:56 -0800
    Subject: proposed versioning usage scenario for client-managed checkouts
    
    
    Jim asked me to write up a protocol usage scenario for the case where the
    client 
    is managing the checkouts as "tokens" rather that using the full workspace
    support 
    a server might have.  This is the impetus behind the "lightweight" workspace
    concept.
    
    Below is a first draft...
    
    
    Client Managed Checkouts
    
    Sally is writing a client tool, SuperEdit, that interoperates with a DAV
    version store.  
    In SuperEdit, an isolated copy of her project files is maintained on the
    user's client 
    system.  She uses the DAV version store for staging, object versioning, and 
    configuration management.
    
    Initially, the user (Spike) specifies a path to a DAV collection that
    represents his 
    project.  SuperEdit then issues the following DAV requests:
    	-	PROPFIND to determine the contents of the folder and the
    settings of 
    	important properties on the folder and its items
    	-	GET on each of the items in the folder which are written to
    the client's 
    	local disk
    
    From within SuperEdit, Spike selects a file an issues the CHECKOUT command.
    
    SuperEdit then issues the following DAV requests:
    	-	CHECKOUT on the selected file(s) without specifying a target
    selector 
    	header
    
    In the response header, SuperEdit finds the workspace that was allocated for
    the 
    checkout.  SuperEdit then stores this ID in its meta-base.
    
    Spike proceeds to edit the file and saves the changes to his local system.
    Eventually 
    he selects the "checkpoint" command.  SuperEdit then issues the following
    DAV 
    requests:
    	-	PUT on the selected file(s) specifying the IDs returned from
    the CHECKOUT 
    	method as the target selectors
    
    The purpose of the checkpoint command is to create a staged, but not yet
    checked in 
    version of the file.  Spike may, or may not, create a checkpoint.
    
    Later, Spike issues the CHECKIN command on a selected set of files.
    SuperEdit 
    then issues the following DAV requests:
    	-	PUT on the selected file(s) that have not been check pointed
    or that have 
    	been modified since being check pointed, specifying the IDs returned
    from 
    	the CHECKOUT method as the target selectors
    	-	CHECKIN on the selected file(s) specifying the IDs returned
    from the 
    	CHECKOUT method as the target selectors