Beyond the standard HTTP PUT method (which creates or overwrites a web resource), WebDAV defines new COPY and MOVE methods for duplicating or rearranging resources.

This is simply the WebDAV term for a grouping of resources (URIs). In most cases, it is analogous to a “directory”. You can tell something is a collection if it ends with a trailing “/”. Whereas file resources can be written or created with a PUT method, collection resources are created with the new MKCOL method.

This is the same idea present in Subversion—metadata attached to files and collections. A client can list or retrieve properties attached to a resource with the new PROPFIND method, and can change them with the PROPPATCH method. Some properties are wholly created and controlled by users (e.g. a property called “color”), and others are wholly created and controlled by the WebDAV server (e.g. a property that contains the last modification time of a file). The former kind are called “dead” properties, and the latter kind are called “live” properties.

A WebDAV server may decide to offer a locking feature to clients—this part of the specification is optional, although most WebDAV servers do offer the feature. If present, then clients can use the new LOCK and UNLOCK methods to mediate access to a resource. In most cases these methods are used to create exclusive write locks (as discussed in the section called “The Lock-Modify-Unlock Solution”), although shared write locks are also possible.

Like CVS and other version-control systems, DeltaV assumes that each resource has a potentially infinite number of states. A client begins by placing a resource under version control using the new VERSION-CONTROL method. This creates a new Version Controlled Resource (VCR). Every time you change the VCR (via PUT, PROPPATCH, etc.), a new state of the resource is created, called a Version Resource (VR). VCRs and VRs are still ordinary web resources, defined by URLs. Specific VRs can have human-friendly names as well.

Some DeltaV servers support the ability to create a virtual “workspace” on the server, where all of your work is performed. Clients use the MKWORKSPACE method to create a private area, then indicate they want to change specific VCRs by “checking them out” into the workspace, editing them, and “checking them in” again. In HTTP terms, the sequence of methods would be CHECKOUT, PUT, CHECKIN. After each CHECKIN, a new VR is created, and the edited VCR's contents now “point to” the latest VR. Each VCR has also has a “history” resource which tracks and orders its various VR states.

Some DeltaV servers also support the idea that the client may have a private working copy full of specific VRs. (This is how CVS and Subversion work.) When the client wants to commit changes to the server, it begins by creating a temporary server transaction (called an activity) with the MKACTIVITY method. The client then performs a CHECKOUT on each VR it wishes to change, which creates a number of temporary “working resources” in the activity, that can be modified using PUT and PROPPATCH methods. Finally, the client performs a CHECKIN on each working resource, which creates a new VR within each VCR, and the entire activity is deleted.

DeltaV allows you define flexible collections of VCRs called “configurations”, which don't necessarily respond to particular directories. Each VCR's contents can be made to point to a specific VR using the UPDATE method. Once the configuration is perfect, the client can create a “snapshot” of the whole configuration, called a “baseline”. Clients use the CHECKOUT and CHECKIN methods to capture specific states of configurations, much like they use these methods to create specific VR states of VCRs.

DeltaV defines a new method, REPORT, which allows the client and server to perform customized data exchanges. The client sends a REPORT request with a properly-labeled XML body full of custom data; assuming the server understands the specific report-type, it responds with an equally custom XML body. This technique is very similar to XML-RPC.

For many, this is the “killer” feature of DeltaV. If the DeltaV server supports this feature, then basic WebDAV clients (i.e. those unaware of versioning) can still write to the server, and the server will silently perform versioning anyway. In the simplest example, an ignorant PUT from a basic WebDAV client might be translated by the server as a CHECKOUT, PUT, CHECKIN.