A Two-Level Versioning Protocol Proposal

Geoffrey M. Clemm (gclemm@tantalum.atria.com)
Wed, 27 Jan 1999 00:45:24 -0500


Date: Wed, 27 Jan 1999 00:45:24 -0500
Message-Id: <9901270545.AA21037@tantalum>
From: "Geoffrey M. Clemm" <gclemm@tantalum.atria.com>
To: ietf-dav-versioning@w3.org
Subject: A Two-Level Versioning Protocol Proposal


This draft is rather terse, but it lays out the terminology and much
of the details of a comprehensive two level versioning protocol proposal.

In this document, I have tried to bring back some key elements of Jim
Whitehead's original proposal (in particular, the vportal concept),
and unify Chris Kaler's series of protocol proposals with the
document-versioning requirements expressed by Bruce Cagan and my
own experience with the design and implementation of a variety of
"high-end" CM systems.

Jim Amsden and I will work this week to resolve any conflicts between
this proposal and his versioning model and goals documents.

Cheers,
Geoff Clemm

---------------------------------------------------------------------


WebDAV Working Group                                            G. Clemm
INTERNET-DRAFT                                         Rational Software
draft-clemm-webdav-versioning-00

Expires July 26, 1999                                   January 26, 1999


                    Versioning Extensions to WebDAV


Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or made obsolete by other documents at
   any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited. Please send comments to
   the Distributed Authoring and Versioning (WEBDAV) working group at
   <w3c-dist-auth@w3.org>, which may be joined by sending a message with
   subject "subscribe" to <w3c-dist-auth-request@w3.org>.

   Discussions of the WEBDAV working group are archived at
   <URL:http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth>.

Abstract

   This document specifies a set of methods, headers, and content-types
   composing the DAV Versioning extensions, an application of the
   HTTP/1.1 protocol to version DAV resources.










draft-clemm-webdav-versioning-00                                [Page 1]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


1.  Introduction

   In this proposal, WebDAV is extended with two classes of versioning
   support: document-management and configuration-management.  To
   maximize interoperability and maximize use of existing protocol
   functionality, document-management is defined as a proper superset of
   the WebDAV advanced-collection protocol, and configuration-management
   is defined as a proper superset of the document-management protocol.

1.1.  Versioning and Locking

   These versioning protocols are designed so that WebDAV locking (class
   2) support is completely optional.  A lock will have it's usual
   semantics, but nothing in either of the versioning protocols depends
   on the presence of locking support.

2.  Document-Management Protocol

   Document-management is the simpler versioning protocol designed to
   support versioning of largely independent resources.  It allows you
   to concurrently access and modify distinct mutable-revisions of a
   resource.

2.1.  Document-Management Resource Types

   Document-management introduces the following additional resource
   types:

2.1.1.  Versionable-Resource

   A versionable-resource is just a standard resource not yet put under
   version control.  A null-resource is a versionable resource.

2.1.2.  Versioned-Resource

   A versioned-resource is a resource that collects and controls all the
   revisions for a resource that has been put under version control.

2.1.3.  Mutable-Revision

   A mutable-revision is a resource that is associated with a
   versioned-resource, and that can be in either a checked-out
   (writeable) or checked-in (readonly) state.

2.1.4.  VPortal

   A vportal is a special kind of reference whose DAV:reftarget property
   is the URL of a versioned-resource.  Reading and writing the body of



draft-clemm-webdav-versioning-00                                [Page 2]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


   a mutable-revision can only be done through a vportal.

   When a PUT is successfully applied to a vportal, a server MAY make
   that change visible at other vportals that select that same mutable-
   revision.  When a CHECKIN is successfully applied to a vportal, the
   state of the mutable-revision at that vportal MUST be made visible at
   all other vportals that select that same mutable-revision.

   This allows the server to cache the PUT information at the vportal,
   and only force the update when the CHECKIN is performed.  A vportal
   otherwise has all the properties and behavior of a normal reference.

   [GMC: I would prefer to simplify the spec by requiring that the
   change is NEVER visible at another vportal until the CHECKIN is
   applied, but I was concerned that some would not find this
   acceptable].

2.2.  Document Management Properties

   Document-management introduces the following additional properties:

2.2.1.  Versioned-Resource Properties

   Document-management introduces the following additional properties
   for a versioned-resource:

2.2.1.1.  DAV:mutable-revisions (readonly collection)

   The DAV:mutable-revisions collection of a versioned-resource contains
   all mutable-revisions of that versioned-resource, where the name of a
   mutable-revision in the DAV:mutable-revisions collection is its
   DAV:mutable-revision-id.  PROPFIND can then be used to gather
   arbitrary information about the mutable-revisions.

2.2.1.2.  DAV:mutable-revision-labels (writeable collection)

   The DAV:mutable-revision-labels collection of a versioned-resource
   contains references to members of the DAV:mutable-revisions
   collection of that versioned-resource.  The client can add and delete
   members of the DAV:mutable-revision-labels collection.  No member of
   this collection can have the same name as a member of the
   DAV:mutable-revisions collection.

2.2.2.  Mutable-Revision Properties

   Document-management introduces the following additional properties
   for a mutable-revision:




draft-clemm-webdav-versioning-00                                [Page 3]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


2.2.2.1.  DAV:mutable-revision-id (readonly, immutable)

   The DAV:mutable-revision-id is an identifier assigned to a mutable-
   revision by the server.  At most one mutable-revision of a given
   versioned-resource will have a particular identifier.

2.2.2.2.  DAV:reservation (readonly, immutable)

   When the DAV:reservation property of a mutable-revision is set, the
   mutable-revision is in a checked-out writeable state.  If the
   DAV:reservation is not set, the mutable-revision is in a checked-in
   readonly state.

2.2.2.3.  DAV:predecessor (readonly, immutable)

   The DAV:predecessor property of a mutable-revision indicates the
   mutable-revision that was selected by the vportal immediately prior
   to the CHECKOUT-NEW request that created this mutable-revision.  The
   DAV:predecessor property is null for the initial mutable-revision
   created by a CONTROL request.

2.2.2.4.  DAV:successors (readonly collection, mutable)

   The DAV:successors collection of a mutable-revision contains
   references to each mutable-revisions whose DAV:predecessor property
   specifies this mutable-revision.

2.2.2.5.  DAV:auto-check-in-out (writeable, immutable)

   When the DAV:auto-check-in-out property of a mutable-revision is set,
   an HTTP-1.1 PUT request to a vportal selecting this mutable-revision
   is automatically preceded by an automatic CHECKOUT and followed by an
   automatic CHECKIN.  This allows a downlevel client to modify a
   version-controlled resource if it is not currently checked-out.

2.2.3.  VPortal Properties

   Document-management introduces the following additional properties
   for a vportal:

2.2.3.1.  DAV:mutable-revision-name (writeable)

   The DAV:mutable-revision-name property of a vportal contains the name
   of a member of either the DAV:mutable-revisions or DAV:mutable-
   revision-labels collections of the versioned-resource referenced by
   that vportal.  This is the mutable-revision that this vportal will
   select unless an explicit Mutable-Revision-Name header is specified.




draft-clemm-webdav-versioning-00                                [Page 4]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


2.3.  Document-Management Methods

   Document-management introduces the following additional methods:

2.3.1.  CONTROL

   A CONTROL request can be applied to a versionable-resource.  When a
   CONTROL request is applied to a versionable-resource, a new
   versioned-resource is created (at a server-assigned URL), an initial
   checked-out mutable-revision for that versioned-resource is created
   (again, at a server-assigned URL), the versionable resource is copied
   to the new mutable-revision, and then the versionable-resource is
   replaced with a vportal that refers to the new versioned-resource and
   whose DAV:mutable-revision-name property is set to be the name of the
   initial mutable-revision.  When the versionable-resource is a null-
   resource, the body of the initial-revision is empty.

   A CONTROL request replaces the original versionable-resource with a
   vportal to ensure that the entire versioned-resource is not deleted
   when a DELETE or MOVE is applied to the original URL of the
   versionable-resource.  This ensures that other vportals to that
   versioned-resource (for example, ones that select different mutable-
   revisions) continue to be valid, and that even when all vportals to
   that versioned-resource have been deleted, the versioned-resource and
   its revisions are retained for historical access.  If the client
   really wants to delete that versioned-resource and all its mutable-
   revisions, DELETE can be applied to the URL of the versioned-resource
   itself.

2.3.2.  MKVPORTAL

   A MKVPORTAL request is used by the client to create a new vportal to
   an existing versioned-resource.  A client can modify the
   DAV:mutable-revision-name property of the vportal to cause it to
   select a different mutable-revision of that versioned-resource.
   [GMC: MKVPORTAL could just be an optional header to CONTROL, if we
   wanted to minimize the number of new methods.]

2.3.3.  CHECKIN

   When a CHECKIN request is applied to a vportal, the mutable-revision
   selected by that vportal is made readonly if it is currently
   checked-out.  A CHECKIN request will fail if the mutable-revision is
   already checked-in.

2.3.4.  CHECKOUT

   When a CHECKOUT request is applied to a vportal, the mutable-revision



draft-clemm-webdav-versioning-00                                [Page 5]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


   selected by that vportal is made writeable if it is currently
   checked-in.  A CHECKOUT request will fail if the mutable-revision is
   already checked-out.

2.3.5.  CHECKOUT-NEW

   When a CHECKOUT-NEW request is applied to a vportal, rather than
   checking out the mutable-revision selected by that vportal, a new
   mutable-revision for that versioned-resource is created, and the
   DAV:mutable-revision-name property of the vportal is modified to
   contain the name of the new mutable-revision.  The new mutable-
   revision is created in a checked-out state and is therefore writeable
   until it is subsequently checked-in.

   The creation of a new mutable-revision of a versioned-resource has no
   effect on vportals that select other mutable-revisions of that
   versioned-resource.  Similarly, the checked-in or checked-out state
   of one mutable-revision is independent of the checked-in or checked-
   out state of any other mutable-revision.

2.4.  Document-Management Headers

   Document management introduces the following additional headers:

2.4.1.  Mutable-Revision-Name

   The Mutable-Revision-Name header is used to override the name
   specified in the DAV:mutable-revision-name property of a vportal.

3.  Configuration-Management Protocol

   Configuration management is a more comprehensive versioning protocol,
   designed to support consistent versioning of sets of related
   resources being modified in parallel by many authors at different
   sites.  The set of resources will commonly be a subtree of the URL
   space at a web site, an entire web site, or a set of subtrees at
   several web sites.  The resources are related by the use of both
   relative and absolute URL references.  To provide a stable
   environment for authoring and change control, controlled sharing
   between distinct workspaces is supported, in addition to the
   branching and merging support required for reliable parallel
   authoring.  In order to maintain the validity of inter-resource
   references, versioning the URL namespace (via versioned collections)
   is as important as versioning the individual documents.

3.1.  Configuration-Management Resource Types

   Configuration-management introduces the following additional resource



draft-clemm-webdav-versioning-00                                [Page 6]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


   types:

3.1.1.  Working-Resource

   A working-resource of a versioned-resource is a writeable resource
   that is created by CHECKOUT or CONTROL.  On a configuration-
   management server, a checked-out mutable-revision of a versioned-
   resource is just a reference to a working-resource of that
   versioned-resource.

3.1.2.  Immutable-Revision

   An immutable-revision of a versioned-resource is a resource created
   by applying a CHECKIN request to a working-resource.  The body and
   immutable properties of an immutable-revision cannot be modified.  On
   a configuration-management server, a checked-in mutable-revision of a
   versioned-resource will always be a reference to an immutable-
   revision of that versioned-resource, and the "CHECKIN history" of a
   mutable-revision is captured by a sequence of immutable-revisions.

3.1.3.  Versioned-Collection

   A versioned-collection is a collection that has been placed under
   version-control.  Versioned-collections are an essential component of
   configuration-management, because they provide the mechanism for
   controlling the URL namespace of a set of related resources.  A
   collection can be placed under version control only if every member
   of that collections is also under version control, therefore every
   member of a revision of a versioned-collection is either a vportal or
   a reference to a vportal.

3.1.4.  Configuration

   A configuration of a versioned-collection provides an immutable
   snapshot of a URL tree of resources rooted at that versioned-
   collection.  To be precise, a configuration of a versioned-collection
   selects an immutable-revision of that versioned-collection, and
   selects an immutable-revision of every immediate member of any
   versioned-collection revision in the configuration.  Therefore, a
   configuration of the root collection of a web site specifies a
   specific state of the web-site as a whole.

3.1.5.  Activity

   An activity is a resource that represents a single logical change
   that may involve modifications to several versioned-resources.  The
   activity collects all immutable-revisions that are created in the
   process of performing that logical change.  An activity is like a



draft-clemm-webdav-versioning-00                                [Page 7]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


   mutable-revision label, in that it allows you to give a meaningful
   name to a particular line of descent, but instead of naming a line of
   descent in just a single versioned-resource, an activity names
   related lines of descent in a set of versioned-resources.

3.1.6.  Workspace

   Finally, a workspace is a resource that describes how version
   selection is to be done across an entire web site.  When a
   versioned-resource is checked out, it is always checked out into a
   specific workspace.  Thus a workspace serves the same purpose for a
   web site as a whole, as a single working-resource does for a single
   versioned-resource.  The root collection of a web site has a property
   indicating the default workspace for that web site.  A Workspace
   header can be used to select a non-default workspace for a request.
   In addition, a workspace can be specified as the DAV:workspace
   property of a vportal to make that the default workspace of the
   vportal.

3.2.  Configuration-Management Properties

   Configuration-management introduces the following additional
   properties:

3.2.1.  Root-Collection Properties

   Configuration-management introduces the following additional
   properties for the root collection of a Web site:

3.2.1.1.  DAV:default-workspace (readonly)

   The DAV:default-workspace property specifies which workspace will be
   used for a request that does contain an explicit Version-Control
   header.  If a vportal has no explicit DAV:workspace property, the
   default workspace of the web site will be used.

3.2.1.2.  DAV:activities (writeable collection)

   The DAV:activities collection of the root collection of a Web site
   contains the activities created at that Web site.

3.2.1.3.  DAV:workspaces (writeable collection)

   The DAV:workspaces collection of the root collection of a Web site
   contains the workspaces created at that Web site.






draft-clemm-webdav-versioning-00                                [Page 8]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


3.2.2.  Versioned-Resource Properties

   Configuration-management introduces the following additional
   properties for a versioned-resource:

3.2.2.1.  DAV:immutable-revisions (readonly collection)

   The DAV:immutable-revisions collection of a versioned-resource
   contains all the immutable-revisions of that versioned-resource.  The
   name of an immutable-revision in this collection is assigned by the
   server.

3.2.2.2.  DAV:working-resources (readonly collection)

   The DAV:working-resources collection of a versioned-resource contains
   all working-resources of that versioned-resource.

3.2.3.  Immutable-Revision Properties

   Configuration-management introduces the following additional
   properties for an immutable-revision:

3.2.3.1.  DAV:immutable-revision-id (readonly, immutable)

   The DAV:immutable-revision-id is an identifier assigned to an
   immutable-revision by the server.  At most one immutable-revision of
   a given versioned-resource will have a particular immutable-revision
   identifier.

3.2.3.2.  DAV:immutable-predecessor (readonly, immutable)

   The DAV:immutable-predecessor is the immutable-revision that was
   checked-out to produce a working resource that was checked-in to
   produce this immutable-revision.

3.2.3.3.  DAV:immutable-successors (readonly collection, mutable)

   The DAV:immutable-successors collection of an immutable-revision
   contains a reference to each immutable-revision whose DAV:predecessor
   is that immutable-revision.

3.2.3.4.  DAV:merge-predecessors (writeable collection, mutable)

   The DAV:merge-predecessors collection of an immutable-revision
   contains references to the other immutable-revisions whose contents
   were explicitly merged by the client into that immutable-revision.
   The client is free to add or delete members to this collection in
   order to more accurately reflect the contents of that immutable-



draft-clemm-webdav-versioning-00                                [Page 9]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


   revision.

3.2.3.5.  DAV:merge-successors (writeable collection, mutable)

   The DAV:merge-successors collection of an immutable-revision contains
   a reference to each immutable-revision whose DAV:merge-predecessors
   collection contains a reference to that immutable-revision.

3.2.3.6.  DAV:reservation (readonly, mutable)

   The DAV:reservation property of an immutable-revision contains the
   URL of a working-resource.  When an immutable-revision is checked-
   out, the DAV:reservation property is set to be the working-resource
   resulting from the checkout.  When a working-resource is checked-in,
   the DAV:reservation of the DAV:immutable-predecessor of the working-
   resource is removed.

3.2.4.  Working-Resource Properties

   Configuration-management introduces the following additional
   properties for a working-resource:

3.2.4.1.  DAV:immutable-predecessor (readonly)

   The DAV:immutable-predecessor of a working-resource is the
   immutable-revision that was checked-out to produce that working-
   resource.

3.2.4.2.  DAV:merge-predecessors (writeable collection)

   The DAV:merge-predecessors collection of a working-resource contains
   references to the immutable-revisions whose contents were explicitly
   merged by the client into that working-resource.  The client is free
   to add or delete members to this collection in order to more
   accurately reflect the contents of that working-resource.

3.2.4.3.  DAV:workspace (readonly)

   The DAV:workspace property of a working-resource contains the URL of
   the current workspace when the working-resource was created by a
   checkout request.

3.2.4.4.  DAV:activity (readonly)

   The DAV:activity property contains the DAV:activity value of the
   workspace into which the working-resource was checked out.





draft-clemm-webdav-versioning-00                               [Page 10]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


3.2.5.  Workspace Properties

   Configuration-management introduces the following additional
   properties for a workspace:

3.2.5.1.  DAV:revision-selection-rule (writeable)

   The DAV:revision-selection-rule of a workspace contains an XML
   document that describes how immutable-revision selection will be
   performed in that workspace.  There will be standard elements for
   specifying common selection mechanisms such as by activity or by
   label, but additional revision-selection-rule elements may be
   supported by a WebDAV server.

3.2.5.2.  DAV:merge-selection-rule (writeable)

   The DAV:merge-selection-rule of a workspace contains an XML document
   that describes what immutable-revisions should be merged into that
   workspace.  The affect of the merge can be determined by a GET-
   CONFLICTS request to the workspace, and the merge itself can be
   performed by an UPDATE request.  There will be standard elements for
   specifying common merge selection mechanisms such as by activity or
   by configuration, but additional merge-selection-rule elements may be
   supported by a WebDAV server.

3.2.5.3.  DAV:auto-descendent-merge (writeable)

   When the DAV:auto-descendent-merge property of a workspace is set,
   and the merge-from immutable-revision (selected by the merge-
   selection-rule) is a descendent of the merge-to immutable-revision
   (selected by the revision-selection rule), the server performs the
   merge automatically when the workspace receives an UPDATE request.
   In particular, it checks out the merge-to immutable-revision, copies
   the merge-from immutable-revision to the new working-resource, adds
   the merge-from immutable-revision to the DAV:merge-predecessors of
   the working-resource, and checks in the working-resource.

3.2.5.4.  DAV:activity (writeable)

   The DAV:activity property of a workspace contains the activity that
   captures the work currently being peformed in that workspace.  The
   immutable-revisions selected by that activity take priority over the
   immutable-revisions selected by the revision-selection-rule.  The
   working-resources checked-out into a workspace take priority over
   immutable-revisions selected by either the revision-selection-rule or
   by the workspace activity.  Thus the version selection algorithm for
   a workspace is "checked-out to that workspace" else "a product of the
   workpace activity" else "selected by the workspace revision-selection



draft-clemm-webdav-versioning-00                               [Page 11]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


   rule".

3.2.5.5.  DAV:dynamic (writeable)

   The DAV:dynamic property indicates whether version selection for a
   workspace is computed dynamically, or whether it is computed only
   following an explicit UPDATE request on that workspace.

3.2.5.6.  DAV:client-workspace (writeable)

   The DAV:client-workspace property indicates whether the working-
   resources for the workspace should be stored on the server or on the
   client.  If it is on the client, the DAV:client-workspace property
   contains a string that indicates "where" on the client the root-
   collection of the workspace can be found.  This string MAY take the
   form of a URL.

3.2.5.7.  DAV:client-updates (readonly)

   The DAV:client-updates property contains an XML document that lists
   the immutable-revisions that were selected by the workspace when the
   most recent UPDATE on that workspace was performed, but that were not
   selected by the workspace when the UPDATE immediately preceding that
   UPDATE had been performed.  This list can be used by the client to
   efficiently maintain a client snapshot of that workspace.  The
   DAV:client-updates property exists only when the DAV:client-workspace
   property is set.

3.2.6.  Activity Properties

   Configuration-management introduces the following additional
   properties for an activity:

3.2.6.1.  DAV:immutable-revisions (readonly collection)

   The DAV:immutable-revisions collection of an activity contains
   references to all immutable-revisions (in any versioned-resource)
   whose DAV:activity property contains this activity.

3.2.6.2.  DAV:branch-policy (writeable):

   The DAV:branch-policy contains an XML document that is used by
   branch-based configuration-management servers to guide the placement
   of immutable-revisions on branches.  Some of the pre-defined values
   XML elements that can appear in this document are:  DAV:branch-on-
   first-checkout, DAV:merge-on-checkin, and DAV:allow-branch-on-
   checkin.




draft-clemm-webdav-versioning-00                               [Page 12]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


3.2.6.3.  DAV:workspace (writeable)

   The DAV:workspace property of an activity indicates the workspace
   which is currently working on that activity (and therefore has the
   right to extend the DAV:immutable-revisions collection of that
   activity).  If any working-resource has its DAV:activity set to a
   given activity, the DAV:workspace of that activity can only be set to
   be the value of the DAV:workspace property of that working-resource.

3.2.7.  Versioned-Collection Properties

   Configuration-management introduces the following additional
   properties for a versioned-collection:

3.2.7.1.  DAV:configurations (readonly)

   The DAV:configurations of a versioned-collection is a versioned-
   resource, each of whose immutable-revisions is a configuration.  New
   immutable-revisions of a DAV:configurations versioned-resource are
   created by a MAKE-CONFIGURATION request (not by CHECKOUT/CHECKIN).

3.2.8.  Collection Properties

   Configuration-management introduces the following additional
   properties for a collection immutable-revision or a collection
   working-resource:

3.2.8.1.  DAV:is-sub-configuration (writeable, immutable)

   In order to increase the efficiency of the creation of a new
   configuration for a versioned-collection, a new configuration can be
   composed from sub-configurations, i.e. configurations of versioned-
   collections that are members of that versioned-collection.  The
   DAV:is-sub-configuration property tells the server whether to select
   (or create, if necessary) a sub-configuration for this versioned-
   collection.

3.3.  Configuration-Management Headers

   Configuration-management introduces the following additional headers:

3.3.1.  Workspace

   The Workspace header specifies the workspace whose version selection
   rules should be used when dereferencing a reference to a versioned-
   resource.  If no Workspace header is specified, the workspace
   specified by the DAV:default-workspace property of the root
   collection is used.



draft-clemm-webdav-versioning-00                               [Page 13]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


3.4.  Configuration-Management Effect on Existing Methods

   When invoked on a configuration-management server, the following
   methods will display additional behavior.

3.4.1.  CONTROL

   A CONTROL request creates a new immutable-revision with an empty
   body, and creates a new working-resource which is a copy of the
   versionable-resource being put under version-control.  The initial
   mutable-revision is a reference to this working-resource.

3.4.2.  CHECKIN

   When a CHECKIN request is applied to a vportal that selects a
   working-resource, it creates a new immutable-revision that is a copy
   of the working-resource (including its properties), updates the
   DAV:immutable-successors collection of the predecessor to contain
   this new immutable-revision, removes the DAV:reservation property of
   the predecessor, and deletes the working-resource.  The mutable-
   revision reference is changed to refer to this immutable-revision.  A
   CHECKIN request fails if it is applied to a vportal that selects an
   immutable-revision, or if a new immutable-revision cannot be created
   as a descendent of the DAV:immutable-predecessor of the working-
   resource.

3.4.3.  CHECKOUT

   When a CHECKOUT request is applied to a vportal that selects an
   immutable-revision, it creates a new working-resource that is a copy
   of the immutable-revision.  The DAV:workspace property of the
   working-resource is set to be the current workspace, and the
   DAV:activity property of the working-resource is set to be the
   DAV:activity of the current workspace.  The CHECKOUT request fails if
   the workspace DAV:activity is not set.

3.4.4.  CHECKOUT-NEW

   A CHECKOUT-NEW request acts like a CHECKOUT request, except that it
   first creates a new activity, and sets the DAV:activity of the
   current workspace to be that activity.  A server may reject a
   CHECKOUT-NEW request if the workspace DAV:activity property is
   already set.

3.5.  Configuration-Management Methods






draft-clemm-webdav-versioning-00                               [Page 14]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


3.5.1.  Activity and Workspace Creation Methods

   Activity and workspace resources can only be created as members of
   the DAV:activities and DAV:workspaces collections.  [GMC: We could
   have a special MKACTIVITY and MKWORKSPACE methods, or we could just
   allow PUT to create them, with the body of the PUT being an XML
   document describing how the resource is to be initialized.  I
   personally find the PUT method cleaner and more extensible because
   you don't need to add a new method to the protocol to handle a new
   resource type.  There does seems to be some preference in the mailing
   group for separate object creation methods, and the use of headers to
   provide initial values.  I'll defer these details for now.]

3.5.2.  UNCHECKOUT

   When applied to a vportal that selects a working-resource, an
   UNCHECKOUT request deletes the working-resource and the
   DAV:reservation property of the predecessor of the working-resource.
   The mutable-revision is changed to refer to the predecessor of the
   working-resource.

3.5.3.  GET-CONFLICTS

   When a GET-CONFLICTS request is invoked on a workspace, the body of
   the GET-CONFLICTS response contains an XML document that describes
   what versioned-resources are in conflict (commonly, a merge
   conflict), as well as information about how to resolve the conflict
   (such as the merge contributors and the merge base).  Merge conflicts
   are determined by the server by comparing the revisions selected by
   the workspace DAV:merge-selection-rule against the revisions selected
   by the DAV:revision-selection-rule at the time of the last UPDATE
   request (or the current time, if DAV:dynamic-selection is set).

3.5.4.  MAKE-CONFIGURATION

   When a MAKE-CONFIGURATION request is invoked on a versioned-
   collection, a new configuration is created that contains the
   revisions currently selected by the workspace for that versioned-
   collection and all its members.

3.5.5.  Security Considerations

   TBD

3.5.6.  Internationalization Considerations

   TBD




draft-clemm-webdav-versioning-00                               [Page 15]

INTERNET-DRAFT      Versioning Extensions to WebDAV     January 26, 1999


3.5.7.  IANA Considerations

   TBD

3.5.8.  XML Element Definitions

   TBD

3.5.9.  References

   TBD

Author's Note:

   A separate document will contain the goals and requirements for these
   protocols.  A separate document will contain use cases and examples
   of these protocols.

Author's  Address:

   Geoffrey M. Clemm
   Rational Software
   Lexington, MA
   geoffrey.clemm@rational.com



























draft-clemm-webdav-versioning-00                               [Page 16]