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.

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 resources 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.

Some DeltaV servers also support the idea that the client may have a private working copy on local disk. 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 resource it wishes to change and sends PUT requests. Finally, the client performs a CHECKIN resource, or sends a MERGE request to check in all resources at once.

DeltaV allows you define flexible collections of resources called “configurations”, which don't necessarily correspond to particular directories. A configuration can be made to point to specific versions of files, and then a “baseline” snapshot can be made, much like a tag.

DeltaV defines a new method, REPORT, which allows the client and server to perform customized data exchanges. While DeltaV defines a number of standardized history reports that a client can request, the server is also free to define custom reports. 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.