2.1.14 Web Versioning and Configuration Management (deltav)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


Jim Amsden <jamsden@us.ibm.com>

Applications Area Director(s):

Keith Moore <moore@cs.utk.edu>
Patrik Faltstrom <paf@swip.net>

Applications Area Advisor:

Keith Moore <moore@cs.utk.edu>

Mailing Lists:

General Discussion:ietf-dav-versioning@w3.org
To Subscribe: ietf-dav-versioning-request@w3.org
In Body: subscribe
Archive: http://lists.w3.org/Archives/Public/ietf-dav-versioning/

Description of Working Group:

This working group will define extensions to HTTP and the WebDAV Distributed Authoring Protocol necessary to enable distributed Web authoring tools to perform, in an interoperable manner, versioning and configuration management of Web resources.

Versioning, parallel development, and configuration management are important features for remote authoring of Web content. Version management is concerned with tracking and accessing the history of important states of a single Web resource, such as a standalone Web page. Parallel development provides additional resource availability in multi-user, distributed environments, letting authors make changes on the same resource at the same time, later merging together those changes. Configuration management addresses the problems of tracking and accessing multiple interrelated resources over time as sets of resources, not simply individual resources. Traditionally, artifacts of software development, including code, design, test cases, requirements, help files, and more have been a focus of configuration management. Web sites, comprised of multiple inter-linked resources (HTML, graphics, sound, CGI, and others), are an important class of complex information artifacts that benefit from the application of configuration management.

The WebDAV working group originally focused on defining version management capabilities for remote authoring applications. However, it has become clear that while versioning functionality alone is useful for a range of content authoring scenarios involving one, or a small set of resources, versioning alone is insufficient for managing larger sets of content. Protocol support for parallel development and simple remote configuration management of Web resources provides functionality for managing larger sets of interrelated content developed by multiple users at different locations.

A sub-group of the WebDAV working group has developed functional requirements for versioning and configuration management of Web content. These requirements encompass the following capabilities, which shall be considered by this working group:


* Naming and accessing resource versions and configurations

* Creating new revisions of a resource

* Placing a resource under version and configuration control

* Parallel development

* History retrieval

* Differencing

* Merging of revisions and configurations

* Operations on configurations

* Mapping resource versions and configurations to the URL namespace

* Versioning support for downlevel HTTP and WebDAV clients

Further information on these objectives can be found in the document, "Goals for Web Versioning".


* HTTP server to server communication protocols

* Development process management, workflow, or change request management

* Versioning and configuration management via non-HTTP and WebDAV protocols.

* Implementation of functionality by non-origin proxies


The following documents are expected to form the final output of this working group.

1. A goals document, which describes the high-level functional requirements for remote versioning and configuration management, including rationale.

2. A model document, which describes the semantics of versioning, configuration management, and parallel development in a protocol independent fashion.

3. A protocol specification, which describes new HTTP methods, headers, request bodies, response bodies, and WebDAV properties to implement the remote versioning and configuration management goals.

4. A traceability document, which describes the mapping between goals and protocol features.

Goals and Milestones:

Oct 99


(Goals) Create final version of distributed versioning and configuration management goals document. Submit for approval as Informational RFC.

Oct 99


(Specification, Model) Produce revised model document, and distributed versioning and configuration management protocol specification. Submit both as Internet Drafts.

Nov 99


(Meeting, Specification, Model) Meet at Washington, DC IETF and hold working group meeting to review the model document and the distributed versioning and configuration management protocol specification.

Feb 00


(Specification, Model, Traceability) Submit revised model document, and distributed versioning and configuration management protocol specification as Internet Drafts. Submit revised traceability document as an Internet Draft.

Mar 00


(Meeting, Specification, Model) Meet at Adelaide IETF and hold working group meeting to review the model document and

Apr 00


(Specification, Model, Traceability) Submit revised model document, distributed versioning and configuration management protocol specification, and traceability document as Internet Drafts. Hold working group last call for comments on all drafts.

May 00


(Specification, Model, Traceabiluty) Revise model document, distributed versioning and configuration management specification, and traceability document based on WG last call comments, and submit specification to the IESG for approval as a Proposed Standard RFC, and submit the model and traceability documents to IESG as Informational RFCs.


No Request For Comments

Current Meeting Report

Delta-V Breakout Sessions Minutes

Reported by: Jim Amsden

The Delta-V working group held two breakout session held at the Washington IETF November 10 and 11. There were 11 members present: Jim Amsden, Pete Carlson, Mike Chihaya, Jeff McAffer, Tim Ellision, Geoff Clemm, Brad Seargant, Chris Kaler, James Hunt, Jim Whitehead, and Jason Crawford. I would like to thank everyone involved for the excellent work and the high degree of collaboration achieved in the meetings. Thanks to your good work, we are on, or even a little ahead of our charter schedule. I am also very pleased with the progress that was made in resolving the issues. Finally, it is interesting to note that we haven't made any significant changes to the versioning semantics since sometime before our meeting in Concord in July. This is a real good indication of progress. Great work guys!

The next meeting of the working group design team is tentatively scheduled for Feb 16 and 17, 2000 in Seattle. Any member of the Delta-V working group is invited to attend. We'll have more meeting details when they are available. We hope to cover the remaining issues, finish walking through the versioning scenarios and how they are supported by the protocol, and review the updated versioning spec.

Action items:
- Geoff will produce a versioning protocol scenarios appendix similar to what we did in the Delta-V working group to show how the protocol supports the goals scenarios.
- Jim Whitehead will provide some details on how URLs are internationalized.
- Everyone will submit a list of timestamps they think are required.

Here's a list of issues covered. They are ordered roughly by the appearance of the associated semantics in the goals document scenarios. All decisions reached in the Delta-V Working Group and these unsanctioned breakout sessions are recommendations that are subject to the scrutiny of the complete Delta-V Working Group through the mailing list. I invite anyone who has issues with any of these recommendations to make them known through the mailing list and we will reconsider or re-open the issue.

How are the versioning options communicated to clients, and what are they?

We discussed extending OPTIONS to take an entity request body and return an entity response body containing the versioning options marshalled in XML. But after some discussion we opted to extend the REPORT method to play this role rather than extend OPTIONS. This seemed more extensible and less intrusive to the existing OPTIONS method.

Do we need MKRESOURCE, or will allowing PROPPATCH on a null resource do?

This was discussed in the WebDAV Working Group meeting, and we decided to not allow PROPPATCH on a null resource and stick with the MKRESOURCE method.

How is a versionable resource put under version control?

There were suggestions to use CHECKIN or CHECKOUT, but neither of these were quite right. They both had headers or entity body elements that weren't appropriate to something that wasn't checked out, or didn't have a predecessor. So we decided to use a new VERSION method that puts a versionable resource under version control. The VERSION method can take a Depth header to put all the members of a collection under version control in a single request. As with CHECKIN, VERSION requires a workspace specified in the target-selector which provides a current label or activity for identifying the newly created revision.

Note that neither CHECKIN or VERSION apply a user-specified label to the newly created revision. If this is necessary, either use the current-label of the workspace, or use the revision id as a target-selector and apply the label using the LABEL method.

Are revision names URL segments?

We decided that this was required in order to marshall revision names in HTTP headers, and to use them to construct URLs. Revision names that are not valid URL segments can user URL encoding techniques.

How are labels internationalized?

By using URL encoding. Jim Whitehead will provide details in a separate note.

Are revision ids and labels in the same namespace?

After much discussion, most of which was already given on the mailing list, we decided to keep them in separate namespaces and use a "namespace indicator" of id: or label: in the header. The issue that convinced the holdouts (mostly me) was that a client could use a label that would clash with some server generated id at some time in the future. This would restrict the server's ability to generate revision ids. There was some discussion about leaving off the namespace indicator for convenience and returning a error if the revision name was both an id and a label.

What is the semantics of locking on versioning artifacts like versioned resources, revisions, working resources, workspaces, activities, configurations, and baselines?

We decided to defer this issue until Jason Crawford has had a chance to explore locking in the current WebDAV specification. However, since we are no longer using "property collections" to specify WebDAV versioning semantics (see below), there is no need to lock any of the versioning artifacts in order to execute the versioning methods. Therefore the versioning semantics will likely be able to accept standard WebDAV locking semantics without requiring any changes.

Do we need a CHECKPOINT method/capability?

CHECKPOINT creates a new revision, but keeps the resource checked out to allow further changes. It is effectively an atomic CHECKIN followed by a CHECKOUT of the newly created revision. That is, the old revision is no longer checked out, and the working resource has the newly created revision as its predecessor. It was decided to make this a parameter of CHECKIN rather than introduce a new method. This was primarily because all of the CHECKIN semantics must be followed.

Should the target selector be returned in a header for all requests? Echoed on requests that specify it?

The concern is that certain WebDAV versioning unaware proxies might strip off the target selector header causing the server to return an unexpected revision without any error. We agreed that the target selector should be choed on any request that specifies it, and the client can use this information to be sure it got the right version. However, this does not address the larger issue of proxy compatibility with WebDAV extensions. We assume that where WebDAV semantics must be protected by proxy servers, suitably update proxy servers will be provided and configured to achieve the desired results.

What timestamps do we need to collect?

We'll move this to the mailing list for the details. Everyone will submit a list of what they think is needed. All dates use ISO format.

Is depth available on CHECKOUT?


How is the workspace overridden to access a particular revision?

If the server supports versioned collections, there are times when a workspace is used for revision selection, and times where the workspace needs to be overridden with a specific label in the same request. For example, say you want to examine an old version of /projects/401k/index.html without changing your workspace revision selection rule. If you just specify a revision label of "beta2" for index.html, what revisions of the projects and 401k collections are used? There are two possible solutions. One is to use both path-selector and target-selector headers in the request. The path-selector is a revision selector (usually a workspace) that is used to resolve all the URL path segments. The target-selector specifies the revision of the leaf resource (or collection). This is reasonable simple, but relies on there being more stability in the namespaces than the contents or properties of a leaf resource. Another approach is to provide a revision path header that has a segment for each segment in the target URL. This is more complicated, but allows specification of a revision for every segment in the URL path.

What are the versioning levels?

We decided at Concord to eliminate the notion of versioning levels, and have core versioning with a number of optional capabilities. Geoff noticed that a number of the capabilities fell into logical groupings both from the semantics and from the protocol specification that could be used to describe higher levels. We concluded that we would revisit this issue after the protocol is more complete and look to see if it is possible to define a small number of levels that represent a set of capabilities (not necessarily methods) that address a cohesive set of use cases the we could identify as important to achieving interoperability.

Can CHECKIN have depth?

Yes. We also need to be able to specify if the CHECKIN should fail if the resource is not checked out, or be ignored.

Should the semantics of the protocol be specified by using "property collections/resources"?

This issue resulted in a long and complex discussion. The conclusion was that property collections would not be used to specify WebDAV semantics, but that we would introduce new methods that specify the semantics in simpler, more flexible, and method specific ways. This eliminated the locking issues with the versioning artifacts, simplified the protocol, eliminated most of the use of server-generated URLs, and resolved long-standing issues in the working group. We arrived at the conclusion be first examining a simple operation that used property collections - labeling a revision. It became clear in the Delta-V working group meeting that we were relying entirely too much on server-generated URLs and property collections that weren't really collections. For example adding a label to a revision required the following steps:

- Access the labels property of the revision and get its server-generated URL.
- Using this URL, BIND a new member whose segment name is the label.
- The server updated other property collections of the versioned resource

We explored a number of alternatives for specifying labels:
- Use BIND and server-generated URLs for a labels property collection (requires locking the property collection)
- Use PROPPATCH on a labels property (requires locking the revision)
- Extend PROPPATCH to support incremental add/delete of collection properties (collection in the generic sense of set, bag, list, ordered list, etc.).
- Introduce a LABEL method
- Perform operations on the versioned resource with a new XML entity request body

Of all of these approaches, introducing a LABEL method was the simplest and most straightforward. It didn't require locking the revision, didn't introduce integrity issues resulting from PROPPATCH to update a composite property, didn't require extensions to PROPPATCH, didn't require the use of any server-generated URLs, and was very easy to explain.

We then examined all the places where property collections were used in the specification:
1. label (on a revision) M (LABEL)
2. merge predecessor (of a revision) M (MERGE)
3. merge successor (of a revision) M (MERGE)
4. revisions (of a versioned resource) RO
5. labeled revisions (of a versioned resource) M (LABEL)
6. successors (of a revision) RO
7. workspaces (of a revision) RO
8. working resources (in a workspace) RO
9. activities (of a repository) R
10. required activities (of another activity) M (ACTIVITY)
11. activity revisions (revisions modified in that activity) RO
12. configurations (of a repository) R
13. workspaces (of a repository) R
14. (missing) required (configurations of a configuration) M

After examining all of these cases, we determined that they fell into a number of groups:

RO - read only, no update required, simply a live property set as a result of some other method R - associated with a repository and created by MKRESOURCE M - better handled by a separate method because of rich semantics

Since only three methods were being introduced (LABEL, MERGE, and ACTIVITY), we are already beyond 16 methods (a current Apache restriction), and these methods simplified the protocol, we decided to not use property collections. The justification is that there are semantics in the server that are viewed through live properties and must therefore be set by new methods.

Do working resources have server-generated URLs that can be used to access the working resource without a workspace?

Yes, but the protocol design will minimize the places where server-generated URLs are required.

Should there be a default current-label and RSR for a newly created workspace?

Often the current label for a workspace will be the same as the name of the workspace, and this label is the only entry in the workspace RSR. However, this would not be a safe default because users could have the same workspace name in a different collection causing the different workspaces to have the same current-label.

Currently Remaining Issues:

Can a revision selector be a compound name? For example, a specific revision of a configuration to add to the workspace revision selection rule.

Are baselines a kind of configuration or a separate concept? The issue is that if they are configurations, how do we prevent them from being edited?

How are configurations created and members added, removed, or changed? Current approach is a configuration is a kind of collection created with MKRESOURCE and members are added/removed using BIND.

Are repositories necessary?

Do members of a versioned collection have to be versioned resources?

How and when is the checkin policy specified?

Can different workspaces use the same activity?

Should we support "frozen" labels?

How do we report the history of a versioned resource?

Could use REPORT or just get the properties of be versioned resource and let the client do what they want. The issue is performance vs. efficient access of versioning meta-data. Many of the versioning properties are hrefs to other resources. This exposes a lot of server-generated URLs and requires lots of round trips to gather all the information required for a history report. On the other hand, casting the output in an XML document generated by the REPORT method limits client flexibility.

How do we delete a revision?

How does the server determine when it should resolve a URL segment with a workspace RSR, and when the segment is part of some server-specific namespace containing versioning meta-data?

Servers are free to specify what portion of the namespace is reserved for their use for server-generated URLs. The collections in these namespaces need not be subject to workspace revision selection rules.

Do we need to separate merge predecessor from predecessor?

Yes. Merge successor/predecessor is mutable and can change to reflect the actual merge that was performed. Successor/predecessor cannot as it is a result of checkout/checkin.

How is the namespace protected on CHECKOUT?

Say you have /a/b.html checked out, someone deletes /a, and you don't have versioned collections. What happens to /a/b.html? We may need to apply some of the same logic used by LOCK to protect the namespace of locked resources.

What reports provided by the REPORT method will be part of versioning core?

Creating a workspace requires write access on a server. How will this be accomplished to get read-only access to a set of revisions when the user does not have sufficient permission.

The server can provide different access permissions for workspace creation, or access to a controlled collection where they can be created. This may result in a denial of service security issue though.

Delta-V Working Group Meeting Notes

Reported by: Jim Amsden, working group chair

The Delta-V Working Group held its first meeting November 9, 1999 at the Washington, DC IETF. The meeting covered the proposed extensions to WebDAV to support versioning, activities and parallel development, and configuration management. The following are the notes from the meeting.

Chair: Jim Amsden
Notetakers: Jim Whitehead, Pete Carlson - many thanks for the great notes

Meeting begins with a review by Jim Amsden of the meeting agenda, including some scoping of the desired discussion for today's session. The approach taken was to walk through the protocol by showing how the scenarios from the goals document would be communicated to a WebDAV versioning server. The purpose was to review the goals and semantics through the scenarios, sketch how the scenarios are supported by the protocol, and raise any issues. We intentionally did not cover
- clients that maintain their own workspace
- local and disconnected modes (master mode only)
- dynamic resources
- locking pending resolution of locking semantics on unversioned resources
- leveling or optional features. This will come later after we have a complete understanding of the full versioning semantics.

First item is a versioning scenario. (The notes from the overheads are included below). In the scenario, want to:

- create a resource
- update it
- make it a versioned resource
- track its history while making some revisions

Geoff Clemm then presented how the protocol would address this scenario:
- create a resource

PUT /a/x.html
- "some text"

PUT /a/x.html
- "some more text"

{Creates the resource, then updates it once, but it currently isn't under version control.}

At this point in time, there is:

resource: /a/x.html
- creation date: 11/9/1999 1:25PM
- "some more text"

VERSION /a/x.html
- This puts the resource under version control

PROPFIND /a/x.html
- resource now has a new property (versioned-resource):

resource: /a/x.html
- creation date: 11/9/1999 1:25PM
- versioned-resource: {some URL "zz157"} <-- the URL where you can retrieve the entire versioned resource
- "some more text"

Need to create a workspace to isolate your changes from those of other collaborators.

MKRESOURCE /workspaces/geoff_dev
- current-label: geoff_dev_lbl
- revision selection rule:
- <label>geoff_dev_lbl
- </label>

This creates a new workspace, where items are assigned the label "geoff_dev_lbl" and the revision selection rule always picks out the revision where the label is "geoff_dev_lbl".

--> /workspaces/ was previously created, and established as the place people store their workspaces.

CHECKOUT /a/x.html
Target-selector: workspace /workspace/geoff_dev

Chris Kaler noted that this checkout will fail, because as of this point, no label has been set on /a/x.html (wasn't done by VERSION, or by GET). This leads to some discussion on how to resolve the problem. Two choices, either have VERSION set a initial label, or can change the revision selection rule. Geoff proposed to modify the revision selection rule. Kevin Wiggen noted that the MKRESOURCE didn't specify that it's creating a workspace resource. So, MKRESOURCE now looks like:

MKRESOURCE /workspaces/geoff_dev
- resource-type: workspace
- current-label: geoff_dev_lbl
- revision selection rule:
- <label>geoff_dev_lbl
- </label>
- <latest/> <or/>

What does "zz157" (the URL of the versioned resource) look like?

- resource-type: versioned-resource
- revisions: /zz157/revisions

Issue: what is inside the "revisions" tag. Is it a collection, or a report? This has not yet been resolved. (Note: this issue was discussed and resolved in the breakout session the following day. See the meeting notes for details.)

Working on the assumption it is a collection:


Further assuming the server names its revisions as "r{version id}", then the versioned resource now has:

/zz157/revisions/r1 <-- this is the stable, reliable name of the revision. A GET on this returns revision 1 of /a/x.html

There is also a collection for labeled revisions:


At present, since no label has been assigned, this is empty. Return back to editing.

So, do a PUT to write into the currently checked-out working resource at /a/x.html. The working resource is part of the workspace, that is, it lives in /workspaces/geoff_dev/...

PUT /a/x.html
- "final text"
- Target-selector: workspace /workspace/geoff_dev

Then, check it in:

CHECKIN /a/x.html
- Target-selector: workspace /workspace/geoff_dev

The act of checking in the resource sets the label on that revision (revision 2). Going back to zz157, there are now the following resources in /zz157/revisions:

- "some more text"

- "final text"

Also, in /zz157/labeled_revisions/, there is:


This is the same resource as /zz157/revisions/r2.

A question was raised about the use of labels. Are they used to track each user? Chris Kaler: no, it's more tracking a line of work. Q: So, your exploiting a side effect of labels here. GC: yes.

Some back and forth on how labels are used, and their role, especially in keeping clients separate.

Question about what a label really is. Geoff answered by giving details on exactly how the label is expressed:

labels: <label>geoff_dev</label>

Geoff emphasized that you can have multiple labels set on a resource. More discussion on uses of labels. Labels are not particularly good for audits.

Q: Can the same label be used across multiple resources? A: yes, definitely.

This ends the first scenario. Now, move on to a scenario involving parallel development. Build on the end state of the first scenario:

User Jim checks out a revision of /a/x.html with label geoff_dev_lbl

User Geoff checks out a revision of /a/x.html with label geoff_dev_lbl

Need a new workspace for Jim:

MKRESOURCE /workspaces/jim_dev
- resource-type: workspace
- current-label: jim_dev_lbl
- revision-selection-rule: <label>jim_dev_lbl</label>
- <label>geoff_dev_lbl</label>

CHECKOUT /a/x.html
- Target-selector: workspace /workspaces/jim_dev

But, immediately after this, the server sees:

CHECKOUT /a/x.html
- Target-selector: workspace /workspaces/geoff_dev

After both checkouts, /zz157/revisions/r2 looks like:

- "final text"

labels <label>geoff_dev_lbl</label>

workspaces: /workspaces/jim_dev/

As each person checks in, the items in workspaces go away, and revisions are added to the successors list:

successors: /zz157/revisions/r3

Now, we want to:
- retrieve the history listing (list predecessors and successors)
- add/remove labels

At present, to make a history listing, need to go to the versioned resource and retrieve the URL of its revision collection, and then do a PROPFIND with Depth to retrieve the predecessor and successor relationships off each individual resource. Could potentially have an optimization to PROPFIND to handle the first two retrievals. Also have the option to do a REPORT method invocation (handles actions that require a lot of computation on the server), with one report being a history listing. Could also have a property on the versioned resource that contains the history listing.

Setting a label:

One option is to go into the labeled revisions collection:


to add a label called "default":

BIND /zz157/revision/r2
Destination: /zz157/labeled-revisions/default

to change it:

BIND /zz157/revision/r4
Destination: /zz157/labeled-revisions/default

Alternately, could use a "LABEL" method:

LABEL /a/x.html
Label-name: default

Lisa Lippert: For simple clients, needing to understand BIND functionality may be too much, and labels may be too complex.

GC: Could be quite simple, a client could just think of the BIND as a "recipe" that they just execute.

LL: If it's so simple, why can't they just do a PROPPATCH?

GC: Could use PROPPATCH {explained a scenario of how to do this}. One drawback of this approach is if there are a large number of labels on a revision, then doing a PROPFIND to retrieve this large set of properties, followed by a PROPPATCH after making a minor modification, could be inefficient.

JH: Every time you have a list of items that needs to be changed, you run into the lost update problem where a modification could be made between PROPFIND and PROPPATCH.

A (many): Yes, this is the case.

Lisa Lippert: Multi-valued properties, in many cases, would be useful if you could add or remove elements from the list. This will be very useful in ACLs, since it'll be useful to add/remove access items, especially if you can't read the items. I'd be happy to work with other people on this.

GC: I'd like to see this too, I certainly like this much better than having a separate method to add/remove list items for each type of list.

Jim W: Is the BIND side-effect to create a label the only reason why labels are exposed through the namespace?

GC: No, the main reason is to have a stable URL for "label X of revision R" to avoid having to create a (revision, label) pair syntax.

Jim Amsden: To finish up, let's request from the WG members their perceptions of the protocol.

Lisa Lippert: I'm concerned about the complexity of the protocol for simple authoring clients. Checkin/checkout, and retrieving a history list have to be really simple.

Yaron Goland: Need to have a document that explains choices, paths not taken, etc. Design rationale.

GC: Agreed -- weren't you going to write this?

Q: Need to list required metadata fields in the specification.

*** Meeting Adjourned ***

- create a resource
- update it
- make it a versioned resource
- make some revisions

PUT /a/x.html
- "some text"

PUT /a/x.html
- "some more text"

VERSION /a/x.html

GET /a/x.html
- "some more text"

MKRESOURCE /workspaces/geoff_dev
- resource_type: workspace-resource-type
- current-label: geoff_dev_lbl
- revision-selection-rule:
- <or> <label> geoff_dev_lbl </label>
- <rsr-latest/>
- </or>

CHECKOUT /a/x.html
- Target-Selector workspace /workspaces/geoff_dev

PUT /a/x.html
- Target-Selector workspace /workspaces/geoff_dev
- "final text"

CHECKIN /a/x.html
- Target-Selector workspace /workspaces/geoff_dev

Scenario 2:

Jim checks out and updates /a/x.html
Geoff checks out and updates /a/x.html
Geoff checks in /a/x.html
Jim checks in /a/x.html

MKRESOURCE /workspaces/jim_dev
- resource_type: workspace-resource-type
- current-label: jim_dev_lbl
- revision-selection-rule:
- <or> <label> jim_dev_lbl </label>
- <rsr-latest/>
- </or>

CHECKOUT /a/x.html
- Target-Selector workspace /workspaces/jim_dev

PUT /a/x.html
- Target-Selector workspace /workspaces/jim_dev
- "Jim's text"

CHECKOUT /a/x.html
- Target-Selector workspace /workspaces/geoff_dev

PUT /a/x.html
- Target-Selector workspace /workspaces/geoff_dev
- "Jim's text"

CHECKIN /a/x.html
- Target-Selector workspace /workspaces/geoff_dev

CHECKIN /a/x.html
- Target-Selector workspace /workspaces/jim_dev

Scenario 3:

List revisions of /a/x.html
List labeled revisions for /a/x.html
Label revision r1 as "default"
Look at revision r1

PROPFIND /a/x.html
- versioned-resource
- versioned-resource: /zz157

- revisions
- labeled-revions
- revisions: /zz157/revisions
- labeled-revisions: /zz157/labeled-revisions

PROPFIND /zz157/revisions
Depth: Infinity
- <href> /zz157/revisions/r1 </href>
- <href> /zz157/revisions/r2 </href>
- <href> /zz157/revisions/r3 </href>

PROPFIND /zz157/labeled-revisions
- Depth: Infinity
- <href> /zz157/revisions/geoff_dev_lbl </href>
- <href> /zz157/revisions/jim_dev_lbl </href>

BIND /zz157/revisions/r1
- Destination /zz157/labeled-revisions/default

GET /zz157/revisions/r1
- "final text"

PROPFIND /zz157/revisions/r1
- labels
- successors
- <labels> <label> default </default> </labels>
- <successors> <href> /zz157/revisions/r2 </href>
- <href> /zz157/revisions/r3 </href> </successors>


None received.