WVCM: The Workspace Versioning and Configuration Management API

Abstract

This document provides an overview of the Workspace Versioning and Configuration Management API.  The WVCM API will minimize the complexity of clients that are capable of interoperating with a variety of repositories.  The WVCM API includes: workspace management, version history management, baseline management, activity management, and namespace versioning.

Table of Contents

1     Introduction. 2

1.1         Relationship to the DeltaV/WebDAV/HTTP Protocols. 2

1.2         Terminology. 2

1.3         Method Preconditions and Postconditions. 5

2     Semantics. 5

2.1         Creating a Workspace. 5

2.2         Sharing Resource Changes. 6

2.3         Modifying a Version-Controlled Resource. 7

2.4         Version-Controlled Folders. 8

2.5         Baseline-Controlled Folders, Configurations, and Baselines. 10

2.6               Activities. 11

2.7               Streams

2.8         Merging. 11

2.9         Unreserved Checkout 12

2.10       Labels. 13

2.11       Locating Version Histories in a Workspace. 13

3     Acknowledgements. 13

4     References. 13

5     Author's Address. 13

 

1        Introduction

This document provides an overview of the Workspace Versioning and Configuration Management (WVCM) API.  There are two key concepts in the WVCM API: "workspaces" and "versioning". 

The purpose of a workspace is to provide an environment within which a user can make persistent modifications to one or more resources without interfering or disrupting the work of other users of those resources.  This requires that the user be able to persist changes to resources (both content changes and naming changes) without those changes being immediately visible to other users.  To provide this functionality, the changes made in one workspace (also known as a "sandbox" or a "view") are visible in other workspaces only after the user of that workspace explicitly exposes those changes for use by other workspaces, and after a user of another workspace explicitly requests to see the changes that have been exposed.

The purpose of versioning is to provide an environment within which previous states of resource (both content and naming) are easily available.  The term "configuration management" is used to emphasize that it is not just isolated resource states that must be easily available, but also consistent configurations of related resources.  The benefits of versioning and configuration management include:

- A resource has an explicit history and a persistent identity across the various states it has had during the course of that history.  It allows browsing through past and alternative versions of a resource.  Frequently the modification and authorship history of a resource is critical information in itself.

- Resource states (versions) are given stable names that can support externally stored references for annotation and linking.  By providing stable states of resources, version-control systems allow not only stable pointers into those resources, but also well defined methods to determine the relationships of those states of a resource.

- Sets of resources can be developed in parallel, and consistent groups of changes can then be exposed for use by other clients.

1.1       Relationship to the DeltaV/WebDAV/HTTP Protocols

To maximize interoperability and the use of existing protocol functionality, the WVCM semantic model is designed to be compatible with the DeltaV [RFC3253], WebDAV [RFC2518], and HTTP [RFC2616] protocols.

1.2       Terminology

Provider

A WVCM "provider" is an implementation of the WVCM API.  Multiple WVCM providers can be available on a single client host and can be used concurrently by a single client.

Resource, Content, Property

A "resource" is a locatable persistent object whose state may contain "content" (an arbitrary sequence of bytes) and a set of "properties" (name/value pairs).

Version-Control, Controlled State, Controlled Properties

When a resource is "version-controllable", a history of the "controlled state" of that resource can be kept by putting it under version-control.  When a resource is put under version-control, it is called a "version-controlled" resource.  The controlled state of a resource includes the content of the resource and a subset of its properties, called the "controlled properties" of the resource.  

Checked Out, Checked In

When a resource is version-controlled, it must be "checked out" in order to modify its controlled state, and then "checked in" to save its current controlled state in the history of that version-controlled resource. 

Version Resource

A "version resource", or simply "version", is a resource that contains a copy of a particular controlled state of a version-controlled resource.  A new version is created whenever a version-controlled resource is checked in.  The server allocates a distinct new location for each new version, and this location will never be occupied by any resource other than that version.  The controlled state captured by a version is immutable.

Predecessor, Successor, Ancestor, Descendant

When a version-controlled resource is checked out and then subsequently checked in, the version that was checked out becomes a "predecessor" of the version created by the checkin.  When a version is connected to another version by traversing one or more predecessor relations, it is called an "ancestor" of that version.  The inverse of the predecessor and ancestor relations are the "successor" and "descendant" relations.  Therefore, if X is a predecessor of Y, then Y is a successor of X, and if X is an ancestor of Y, then Y is a descendant of X.

Version History Resource

A "version history resource", or simply "version history", is a resource that contains all the versions that are descendants of a particular version, called the "root version" of that version history.  A version history is located in a server defined namespace and therefore is unaffected by any deletion or movement of version-controlled resources

Version Name

A "version name" is a string chosen by the server to distinguish one version in a version history from the other versions in that version history.  Versions from different version histories may have the same version name.

Label

A "label" is a string that can be used to select a version from a version history.  A label can be assigned by either a client or the server.  The same label can be used in different version histories.

Folder Resource, Binding, Bound Member, Member, Controlled-Binding

A "folder resource", or simply "folder", is a resource whose state includes a set of "bindings".  Each binding defines a mapping from a name to another resource, called a "bound member" of the folder.  The "members" of a folder are the folder itself and all bound members of any member of the folder.  In mathematical terms, the member relationship is the reflexive and transitive closure of the bound-member relationship. 

The controlled state of a folder includes a set of "controlled-bindings", where a controlled-binding of a version-controlled folder contains the name and version history resource of a version-controlled bound member of that folder.  Because the state of a bound member of a folder is not part of the controlled state of the folder, a folder does not have to be checked out to modify the state of a bound member of the folder.  Because non-version-controlled bound members are not part of the controlled state of a folder, a folder does not have to be checked out to add or remove non-version-controlled bound members.

Workspace Resource

A "workspace resource", or simply "workspace", is a folder whose members are version-controllable resources, and that has at most one member for a given version history.

Configuration Resource, Baseline Resource, Baseline-Control

A "configuration resource", or simple "configuration", is a version-controlled resource whose controlled state includes a version of each of a set of version-controlled resources that are called the members of that configuration.  When a configuration is checked in, the new version of that configuration, called a "baseline resource" or simply "baseline", captures the version identified by the CHECKED_IN property of each member of that configuration.

When a folder is "baseline-controllable", that folder can be put under "baseline-control", which creates a configuration whose members are the members of that folder.  When a folder is put under baseline-control, it is called a "baseline-controlled" folder.  The configuration of a baseline-controlled folder is not part of the controlled state of the folder, so new baselines of a folder can be created without checking out the folder.

Note that a folder (whose state consists of a set of bindings) is very different from its configuration (whose state consists of a set of member resource states).  In particular, a folder version (which captures the name and version history of each of the version-controlled bound members of the folder) is very different from a folder baseline (which captures the checked-in version of each member of that folder).  When a folder is both version-controlled and baseline-controlled, a client can check in the folder to create a new version of that folder, and can check in the configuration of that folder to create a new baseline of that folder.

Fork, Merge

When a second successor is added to a version, this creates a "fork" in the version history.  When a version is created with multiple predecessors, this creates a "merge" in the version history.  A server may restrict the version history to be linear (with no forks or merges), but an interoperable versioning client should be prepared to deal with both forks and merges in the version history.

The following diagram illustrates several of the previous definitions.  Each box represents a version and each line between two boxes represents a predecessor/successor relationship.  For example, it shows V2 is a predecessor of V3, V5 is a successor of V3, V1 is an ancestor of V4, and V7 is a descendant of V4.  It also shows that there is a fork at version V2 and a merge at version V7.

                   Version History of foo.html

    

                             +---+

       Root Version -------> |   | V1

                             +---+           ^

                               |             |

                               |             |

                             +---+           |

                             |   | V2        | Ancestor

                    ^        +---+           |

                    |        /    \          |

       Predecessor  |       /      \         |

                       +---+       +---+

                       |   | V3    |   | V4

                       +---+       +---+

       Successor    |    |           |       |

                    |    |           |       |

                    v  +---+       +---+     |

                       |   | V5    |   | V6  | Descendant

                       +---+       +---+     |

                            \      /         |

                             \    /          |

                             +---+           v

                             |   | V7

                             +---+

 

Activity Resource

An "activity resource", or simply "activity", is a resource that selects a set of versions that correspond to a single logical change, where the versions selected from a given version history are required to form a single line of descent through that version history.

Stream Resource

A "stream resource", or simply "stream", is a special type of activity whose versions are baselines.  

1.3       Method Preconditions and Postconditions

A "precondition" of a method describes the state on the server that must be true for that method to be performed.  A "postcondition" of a method describes the state on the server that must be true after that method has completed.  If a method precondition or postcondition is not satisfied, a WvcmException will be thrown, containing a ReasonCode that identifies the condition that was not satisfied.

2        Semantics

2.1       Creating a Workspace

In order to create a workspace, a client specifies the location of the workspace.  If the workspace is located in a client file system, the location of the workspace would be a client file system folder.  The client can then create, browse, and update workspace members through WVCM API methods, or alternatively, if the workspace is located in a client file system, through native client file system commands.

In order to ensure unambiguous baselining (see Section 2.5) and merging (see Section 2.7) semantics, a workspace cannot contain more than one version-controlled resource for a given version history.  This is required for unambiguous baselining because a baseline can only select one version for a given version-controlled resource.  This is required for unambiguous merging because the doMerge method must identify which version-controlled resource is to be the merge target of a given version.

Initially, an empty workspace can be created.  New resources can then be added to the workspace with methods such as doCreateResource.  Version-controlled resources for existing version histories can be added to the workspace with the doCreateVersionControlledResource method.  Folders in the workspace can be placed under baseline-control, and then initialized by existing baselines.

2.2       Sharing Resource Changes

Multiple workspaces may be used to expose different versions and configurations of a set of version-controlled resources concurrently.  In order to make changes to a version-controlled resource in one workspace visible in another workspace, that version-controlled resource must be checked in, and then the corresponding version-controlled resource in the other workspace can be updated to display the content of the new version. 

In order to share changes to a resource with other workspaces, the client must first put that resource under control using the doVersionControl method.  In order to update the controlled state of a version-controlled resource, a client must first check out that resource using the doCheckout method.  A checked-out resource can then be updated through WVCM API methods or native client file system commands.  When a client is ready to expose the modified state of a version-controlled resource to other workspaces, it must use the doCheckin method.  Note that if a workspace is located in a client file system, a WVCM implementation will commonly mark a checked-in resource as read-only, to prevent local file system commands from incorrectly modifying the checked-in resource.

The doVersionControl method resource performs three distinct operations:

1) It creates a new version history.  Each version history is assigned a new distinct and unique server-defined location.

2) It creates a new version and adds it to the new version history.  The state of the new version is initialized from the content and controlled properties of the version-controllable resource.  The server assigns the new version a new distinct and unique location.

3) It converts the version-controllable resource into a version-controlled resource.  Note that the location of the resource remains unchanged.  As part of this conversion, it adds a CHECKED_IN property that identifies the new version.

In the following example, foo.html is a version-controllable resource that is put under version-control.  After the doVersionControl method succeeds, there are two additional resources: a new version history and a new version in that version history.  The version-controllable resource is converted into a version-controlled resource, whose CHECKED_IN property identifies the new version.  The content of a resource is represented by the symbol appearing inside the box for that resource (e.g. "S1" in the following example). 

          ===doVersionControl==>

    

                    |                       +----+ version

       version-     |   version-            |    | history

       controllable |   controlled          +----+ resource

       resource     |   resource              |

       /foo.html    |   /foo.html             |       

                    |                         v

         +----+     |     +----+ CHECKED_IN +----+ version

         | S1 |     |     | S1 |----------->| S1 | resource

         +----+     |     +----+            +----+ /his/73/ver/1

 

Thus, after the doVersionControl method succeeds there are two additional separate, distinct resources, each containing its own content and properties: the version resource and the version history resource.  Since the version-controlled resource and the version are separate, distinct resources, when a method is applied to a version-controlled resource, it is only applied to that version-controlled resource, and is not applied to the version that is currently identified by the CHECKED_IN property of that version-controlled resource.  Although the controlled state of a checked-in version-controlled resource is required to be the same as that of the version identified by its current CHECKED_IN property, its uncontrolled properties may differ.  An implementation may optimize storage by retrieving the controlled state of a checked-in version-controlled resource from the version identified by its current CHECKED_IN property rather than storing it in the version-controlled resource, but this is just an implementation optimization.

2.3       Modifying a Version-Controlled Resource

In order to modify the controlled state of a version-controlled resource, the version-controlled resource must first be checked out.  When the checked-out resource is checked in, a new version is created in the version history of that version-controlled resource.  The version that was checked out is remembered as the predecessor of the new version. 

The following diagram illustrates the effect of the checkout/checkin process on a version-controlled resource and its version history.  The symbol inside a box (S1, S2, S3) represents the current content of the resource represented by that box.  The symbol next to a box (V1, V2, V3) represents the location of that resource.

 

          ==doCheckout=>  ==doWriteContent=>  ==doCheckin=>

 

 

         /foo.html (version-controlled resource)

 

          +----+    |    +----+    |    +----+    |    +----+

          | S2 |    |    | S2 |    |    | S3 |    |    | S3 |

          +----+    |    +----+    |    +----+    |    +----+

       CHECKED_IN=V2|CHECKED_OUT=V2|CHECKED_OUT=V2|CHECKED_IN=V3

 

 

         /his/73 (version history for /foo.html)

 

         +----+     |   +----+     |   +----+     |   +----+

         | S1 | V1  |   | S1 | V1  |   | S1 | V1  |   | S1 | V1

         +----+     |   +----+     |   +----+     |   +----+

            |       |      |       |      |       |      |

            |       |      |       |      |       |      |

         +----+     |   +----+     |   +----+     |   +----+

         | S2 | V2  |   | S2 | V2  |   | S2 | V2  |   | S2 | V2

         +----+     |   +----+     |   +----+     |   +----+

                    |              |              |      |       

                    |              |              |      |      

                    |              |              |   +----+    

                    |              |              |   | S3 | V3   

                    |              |              |   +----+    

 

2.4       Version-Controlled Folders

As with any version-controllable resource, when a version-controllable folder is put under version-control, a version history resource is created to contain the versions of that folder.  A version-controlled folder must be checked out in order to put a bound member of the folder under version-control, or to add, remove, or rename a version-controlled bound member of the folder.  In order to preserve standard versioning semantics (a version of a folder should not be modifiable), a folder version does not record information about the non-version-controlled bound members of that folder.  In order to allow a new version of a version-controlled resource to be selected without requiring a new version of each of its parents (recursively) to be created, a folder version has version histories, not versions, as its bound members.

In the following example, there are three version histories, named VH14, VH19, and VH24, where VH14 contains versions of a folder.  The version-controlled folder /x has version V2 of version history VH14 as its CHECKED_IN version.  Since V2 has recorded two controlled-bindings, one with binding name "a" to version history VH19, and the other with binding name "b" to version history VH24, /x MUST have two controlled-bindings, one named "a" to a version-controlled resource for history VH19, and the other named "b" to a version-controlled resource for history VH24.  The version-controlled resource /x/a currently has V4 of VH19 as its CHECKED_IN version, while /x/b has V8 of VH24 as its CHECKED_IN version.

 

                                                         VH19

                                                      +---------+

                                                      | +---+   |

                                                      | |   |V4 |

                                                      | +---+   |

                                                      |   |     |

                                                      |   |     |

                                                      | +---+   |

                                                      | |   |V5 |

                                           VH14       | +---+   |

                                       +---------+    |   |     |

                                       | +---+   |    |   |     |

              a  +---+                 | |   |V1 |    | +---+   |

            ---->|   |CHECKED_IN=V4    | +---+   | a  | |   |V6 |

           /     +---+                 |   |   ------>| +---+   |

          /                            |   |  /  |    +---------+

     +---+                             | +---+   |

  /x |   |CHECKED_IN=V2                | |   |V2 |

     +---+                             | +---+   |       VH24

          \                            |   |  \  | b  +---------+

           \  b  +---+                 |   |   ------>| +---+   |

            ---->|   |CHECKED_IN=V8    | +---+   |    | |   |V7 |

                 +---+                 | |   |V3 |    | +---+   |

                                       | +---+   |    |   |     |

                                       +---------+    |   |     |

                                                      | +---+   |

                                                      | |   |V8 |

                                                      | +---+   |

                                                      |   |     |

                                                      |   |     |

                                                      | +---+   |

                                                      | |   |V9 |

                                                      | +---+   |

                                                      +---------+

 

Although a version-controlled folder MAY have both version-controlled and non-version-controlled bound members, a folder version only records information about the version-controlled bound members of the folder.  As a result, non-version-controlled bound members can be added or deleted to a version-controlled folder without checking out the folder.

2.5       Baseline-Controlled Folders, Configurations, and Baselines

A folder can be placed under baseline-control with a doBaselineControl method.  When a folder is placed under baseline-control, the ROOT_FOLDER_OF property of the folder is set to identify a new configuration.  A configuration is a version-controlled resource whose members are the version-controlled members of its root folder.  A version of a configuration is called a baseline, and the version history of a configuration is called a baseline history.  A baseline of a configuration captures the controlled state at a particular time of each member of that configuration.  New baselines are created by checking out and then checking in a configuration.

In the following example, the folder /src is placed under baseline-control, and is populated with members from an existing baseline.  A new configuration (/repo/cfg/128) is created and associated with /src, and /src is initialized with version-controlled members whose CHECKED_IN versions are those selected by the BaselineFolder (/repo/bc/15) of the specified baseline (/repo/blh/13/ver/8).  The following diagram illustrates the resulting state on the server.

     +----------------------------+

     |Baseline-Controlled Folder  |<------+

     |/src                        |       |

     |----------------------------|       |

     |ROOT_FOLDER_OF              +---+   |

     +----------------------------+   |   |

                                      |   |

                                      |   |

     +----------------------------+   |   |

     |Configuration               |<--+   |

     |/repo/cfg/128               |       |

     |----------------------------|       |

     |ROOT_FOLDER                 +-------+

     |----------------------------|

     |CHECKED_IN                  +-------+

     |----------------------------+       |

     |VERSION_HISTORY             +---+   |

     +----------------------------+   |   |

                                      |   |

                                      |   |

     +--------------------+           |   |

     |Baseline History    |<----------+   |

     |/repo/blh/13        |               |

     |--------------------+               |

     |CHILD_BINDING_MAP   +-----------+   |

     +--------------------+    |   |  |   |

                               v   |  v   |

                                   |      |

     +--------------------+        |      |

     |Baseline            |<-------+------+

     |/repo/blh/13/ver/8  |

     +--------------------+

    

 

In order to create new baselines of /src, /repo/cfg/128 can be checked out, new versions can be created or selected by the version-controlled members of /src, and then /repo/cfg/128 can be checked in to capture the current state of those version-controlled members.

2.6       Activities

An activity is a resource that selects a set of versions that are on a single "line of descent", where a line of descent is a sequence of versions connected by successor relationships.  If an activity selects versions from multiple version histories, the versions selected in each version history must be on a single line of descent.

A common problem that motivates the use of activities is that it is often desirable to perform several different logical changes in a single workspace, and then selectively merge a subset of those logical changes to other workspaces.  An activity can be used to represent a single logical change, where an activity tracks all the resources that were modified to effect that single logical change.  When a version-controlled resource is checked out, the user specifies which activity should be associated with a new version that will be created when that version-controlled resource is checked in.  It is then possible to select a particular logical change for merging into another workspace, by specifying the appropriate activity in a doMerge method.

Another common problem is that although a version-controlled resource may need to have multiple lines of descent, a particular team may want all work done by members of that team to be on a single line of descent (to avoid merging between team members).  An activity resource provides the mechanism for addressing this problem.  When a version-controlled resource is checked out, a client can request that an existing activity be used or that a new activity be created.  Activity semantics then ensure that all versions in a given version history that are associated with an activity are on a single line of descent.  If all members of a team share a common activity, then all changes made by members of that team will be on a single line of descent.

The following diagram illustrates activities.  Version V5 is the latest version of foo.html selected by activity Act-2, and version V8 is the latest version of bar.html selected by activity Act-2.

             foo.html History       bar.html History

  

                   +---+                  +---+

              Act-1|   |V1           Act-1|   |V6

                   +---+                  +---+

                     |                      |

                     |                      |

                   +---+                  +---+

              Act-1|   |V2           Act-2|   |V7

                   +---+                  +---+

                  /     \                   |

                 /       \                  |

            +---+         +---+           +---+

       Act-1|   |V3  Act-2|   |V4    Act-2|   |V8   

            +---+         +---+           +---+

                            |               |

                            |               |

                          +---+           +---+

                     Act-2|   |V5    Act-3|   |V9

                          +---+           +---+

 

Activities appear under a variety of names in existing versioning systems.  When an activity is used to capture a logical change, it is commonly called a "change set".  When an activity is used to capture a line of descent, it is commonly called a "branch".

2.7       Streams

For high-end SCM systems that implement efficient baselining, an activity whose versions are baselines is sufficient for most team collaboration (baselines are created and then merged into the workspaces of other team members). But for lower end systems, for which baselines are expensive (commonly implemented by labeling every version in the configuration) something like a floating label is used to remember the shared configuration, and only important configurations are baselined. To support these systems, a special kind of activity called a "stream" is defined, where a stream is an activity whose versions are Baselines, and logically acts as a "floating baseline" (i.e. a baseline with a VERSION_LIST that can be modified). The VERSION_LIST of a stream is updated on every checkin to a workspace whose STREAM property identifies that stream. In addition, a doUpdate() method can be used to update the versions selected by the VERSION_LIST of the stream.

2.8       Merging

When a user wants to accept the changes (new versions) created by someone else, it is important not just to update the version-controlled resources in the user's workspace with those new versions, since this could result in "backing out" changes the user has made to those version-controlled resources.  Instead, the versions created in another workspace should be "merged" into the user's version-controlled resources.

The version history of a version-controlled resource provides the information needed to determine the result of the merge.  In particular, the merge should select whichever version is later in the line of descent from the root version.  In case the versions to be merged are on different lines of descent (neither version is a descendant of the other), neither version should be selected, but instead, a new version should be created that contains the logical merge of the content of those versions. 

The doMerge method performs the logical merge of a specified version (the "merge source") into the version-controlled resource (the "merge target").  If the merge source is neither an ancestor nor a descendant of the CHECKED_IN or CHECKED_OUT version of the merge target, the doMerge checks out the merge target (if it is not already checked out) and adds the merge source to the MERGE_LIST of the merge target.  It is then the client's responsibility to update the content of the checked-out merge target so that it reflects the logical merge of the merge source into the current state of the merge target.  The client indicates that it has completed the update of the merge target by checking in the checked-out merge target.

When a server has the ability to automatically update the content of the merge target to reflect the logical merge of the merge source, it may do so unless NO_AUTO_MERGE is specified in the doMerge method.  In order to notify the client that a merge source has been automatically merged, the doMerge method MUST add the auto-merged source to the AUTO_MERGE_LIST property of the merge target, and not to the MERGE_LIST property.

Multiple merge sources can be specified in a single doMerge method.  The set of merge sources for a doMerge method is determined from the sourceList of the doMerge method as follows:

- If a sourceList member identifies a baseline, that baseline is a merge source.

- If a sourceList member identifies a version-controlled resource, the CHECKED_IN version of that version-controlled resource is a merge source.

- If a sourceList member identifies a folder, the CHECKED_IN version of each version-controlled resource that is a member of that folder is a merge source.

- If a sourceList member identifies an activity, then for each version history containing a version selected by that activity, the latest version selected by that activity is a merge source.

Any member of the workspace is a possible merge target.  The merge target of a particular merge source is the version-controlled resource whose CHECKED_IN or CHECKED_OUT version is from the same version history as the merge source.  If a merge source has no merge target, that merge source is ignored.

If the merge source is a baseline, the merge target is a configuration for the baseline history of that baseline, where the root folder of that configuration is a member of the workspace.

2.9       Unreserved Checkout

The UNRESERVED property on a checked-out version-controlled resource indicates whether the ACTIVITY_LIST of another checked-out resource associated with the version history of this version-controlled resource can have an activity that is in the ACTIVITY_LIST property of this checked-out resource.

A result of the requirement that an activity must form a single line of descent through a given version history is that if multiple checked-out resources for a given version history are checked out unreserved into a single activity, only the first doCheckin will succeed.  Before another of these checked-out resources can be checked in, the user will first have to merge into that checked-out resource the latest version selected by that activity from that version history, and then modify the PREDECESSOR_LIST of that checked-out resource to identify that version.

2.10   Labels

A version "label" is a string that distinguishes one version in a version history from all other versions in that version history.  A label can automatically be assigned by a server, or it can be assigned by a client in order to provide a meaningful name for that version.  A given version label can be assigned to at most one version of a given version history, but client assigned labels can be reassigned to another version at any time.  Note that although a given label can be applied to at most one version from the same version history, the same label can be applied to versions from different version histories.

2.11   Locating Version Histories in a Workspace

Many properties identify a version from some version history.  It is often useful to be able to efficiently locate a version-controlled resource for that version history.  The doLocateByHistoryReport method can be applied to a workspace to locate the workspace member that is a version-controlled resource for one of the specified version history resources.

3        Acknowledgements

This API is the collaborative product of the author, the original JSR-147 design team (Nick Crossley, Tim Ellison, Peter Raymond, and Eric Sedlar), and the rest of the JSR-147 expert group (Manfred Baedke, Tobias Bocanegra, John Dooley, Martin Entlicher, Stefan Guggisberg, Alison Macmillan, Peter Nevermann, Pieter Piegaze, Juergen Pill, Donald Tam).   We would like to acknowledge the foundation laid for us by the authors of the DeltaV protocol.

4        References

[RFC2518] Y.Goland, E.Whitehead, A.Faizi, S.R.Carter, D.Jensen, "HTTP Extensions for Distributed Authoring - WEBDAV", RFC 2518, February 1999.

[RFC2616] R.Fielding, J.Gettys, J.C.Mogul, H.Frystyk, L.Masinter, P.Leach, and T.Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[RFC3253] G.Clemm, J.Amsden, T.Ellison, C.Kaler, J.Whitehead, "Versioning Extensions to WebDAV", RFC 3253, March 2002.

5        Author's Address

Geoffrey Clemm

IBM

20 Maguire Road, Lexington, MA 02421

 

Email: geoffrey.clemm@us.ibm.com