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]