12.7 DeltaV Features and Packages

In DeltaV, the functionality that can be offered is divided into named features. Support for each feature can be advertised in the OPTIONS response by including the feature name in the DAV: header. There are 11 named features, and only one (the version-control feature) is required.

The DeltaV authors realized that the abundance of optional features presented a problem: No client could be expected to interoperate with all the possible variations of server functionality (there are 2¹⁰ theoretical combinations of advertised features). In an attempt to deal with this issue, several packages were defined; a package is a set of features. None of the packages can be advertised (in OPTIONS response or elsewhere), so the client must look for each feature involved in a package to see if the server supports the package. DeltaV only requires that the server "should" support one of the defined packages, so supporting a package is not strictly required.

In addition to the advertised features, major functionality differences can be inherent in how servers allow and forbid operations and property values. For example, if the server never allows the auto-version property to be set to a value, that implies that the server does not support automatic versioning at all. Another example is that if the server forbids checking out a version that already has a successor, the server does not support branches. These variations in supported functionality can only be discovered through trial and error and much examination of property values.

Certain features are arbitrarily defined in the DeltaV specification as "Basic" features. The "Advanced" features are supposed to add functionality for parallel development and configuration management, yet the workspace feature is Basic and the merge feature is Advanced.

12.7.1 Basic Features

The version-control feature is the minimal feature set required by a server claiming to support DeltaV. It exposes the DeltaV data model, including a simple way of checking out and checking in a resource. All the other Basic features are optional, and they all require the version-control feature (see Table 12-1).

Table 12-1. Basic Versioning Features and Concepts

version-control	How to make a nonversioned resource into a VCR. How to automatically create new versions of VCRs when they are changed. Resource: VCR, version Methods: VERSION-CONTROL, REPORT Reports: version-tree, expand-property
checkout-in-place	How to check out a VCR, make several changes, and check in a single new version. How to indicate forking support. Methods: CHECKIN, CHECKOUT, UNCHECKOUT
version-history	How to collect a related set of versions, no matter how many VCRs point to that set of versions and even if all VCRs pointing to that set have been deleted. Resource: Version-History Resource Report: locate-by-history
workspace	How to collect several related works-in-progress into a single place (the workspace). How to add a new item to the workspace (VERSION-CONTROL). Resource: Workspace resource Method: MKWORKSPACE
update	How to change the target version of a VCR. Method: UPDATE
label	How to identify versions. Method: LABEL Header: Label
working-resource	How to create a single resource on the server, to serve as a place where a work-in-progress can be edited in private. Methods: CHECKOUT (on a version), CHECKIN, UNCHECKOUT (on a working resource) Resource: Working Resource

12.7.2 Advanced Features

The advanced DeltaV features are related to configuration control (see Table 12-2). Since a configuration is a set of related VCRs, configuration control is how you manage those files. In other words, configuration management solves the problems encountered in multifile versioning. Configuration control is uniquely found in source control systems, where many code files must work together. Configuration management is done through baselines, activities, and version-controlled collections.

Table 12-2. Quick Reference of Concepts Introduced in Each Advanced Feature

merge	How to combine changes made in a workspace's resources with the original source resources. Method: MERGE Report: merge-preview
baseline	How to identify the set of related versions of a number of version-controlled resources. Resources: baseline, baseline history, version-controlled configuration Method: BASELINE-CONTROL Report: compare-baseline
activity	How to track a single logical change affecting multiple resources (such as adding a new feature to a software project involving multiple source files). How to merge this activity (logical change) into the main repository. How to branch a version-controlled resource. Resource: activity Method: MKACTIVITY Report: latest-activity-version
version-controlled-collection	How to track changes to collections (their list of members) as a history of collection versions. Resource: Version-controlled collection, collection version, working collection

12.7.3 Core Versioning Package

The core versioning package is just the version-control feature. Although it may seem extremely limited by the lack of explicit checkin and checkout ability, a versioning-aware client can gain a modest amount of control over the way versions are created by knowing how LOCK and UNLOCK interact with auto-versioning. A versioning-aware client can also create VCRs and can easily explore past versions of existing VCRs.

12.7.4 Client Workspace Package

The basic client workspace package assumes that most of the development and coordination of content takes place on the client machine. The basic client workspace package consists of:

• version-control

• working-resource

• update

• label

The client workspace package is for systems where the general assumption is that ongoing changes are saved only on each developer's machine. During this time, other users don't see the changes in progress. Other users see the modifications only when the files are checked in.

To make this model work, clients create working resources with every checkout. The client can actually upload the contents at any time, but since working resources generally don't appear to other users, the changes aren't seen until checkin. Thus checkout-in-place is not part of this model, even though it might be useful to handle non-DeltaV clients.

A well-known source control system with approximately this model is CVS. However, the terminology used in CVS is rather different from that used in DeltaV. For example, a CVS "checkout" is an operation that downloads initial copies of all the VCRs from the server to the client and is only done once, when a user starts working on a new CVS module. In DeltaV, this is done with GET. A CVS "update" downloads and merges new content (for a module that has already been "checked out" in the CVS sense). In DeltaV, this is done with GET and PROPFIND (and the client is responsible for doing merges locally). Finally, a CVS "commit" operation uploads one or many changes to the server, creating a new version of each changed resource. In DeltaV, this is done with CHECKOUT, PUT, PROPPATCH, and CHECKIN for each changed resource. The terminology differences don't prevent DeltaV from being used as a framework for standards-based access to a CVS-style server.

DeltaV also defines an advanced client workspace package, which adds all the advanced features (merge, baselines, activities, version-controlled collections).

12.7.5 Server Workspace Package

In the basic server workspace model, clients are expected to do their work largely on the server. Many more PUT and PROPPATCH operations will be expected. The basic server workspace package includes:

• version-control

• workspace

• version-history (required by workspace)

• checkout-in-place

Server workspaces have several advantages over client workspaces. First, with a client workspace, there may be a greater chance that work in progress will be accidentally lost, because the client machine is likely to be less reliable than the server repository. Second, the author may find it inconvenient to store work-in-progress on the client machine if the author ever has to use another machine, because the work-in-progress isn't automatically transferred between one client machine and another. More rarely, multiple users may want to collaborate on a file in a workspace. Server-side workspaces are sometimes supported in order to achieve the benefits of workspaces without the disadvantages of storing them on the client machine. However, a slow server or slow connection can make this model less usable.

DeltaV also defines an advanced server workspace package, which adds all the advanced features (merge, baselines, activities, version-controlled collections).

12.7.6 Feature Dependencies

The DeltaV specification points out some feature dependencies. For example, it's impossible to construct a workspace without VHRs, so the workspace feature requires support for the version-history feature. In addition, there are near-dependencies, where one feature isn't very useful without another. For example, the merge feature isn't very useful unless version trees have forks, and forks aren't common unless the server supports either working resources or workspaces.

Workspace and Other Features

Workspaces are much more useful with the merge and update features supported as well, yet workspace is part of the basic server workspace package, and merge and update aren't.

Merge is the primary mechanism to make work from one workspace appear in another workspace. Update is also useful because when a VCR inside a workspace is checked in, this won't automatically affect the checked-in property of the other VCRs that point to the same VHR. The client must send an UPDATE request to the VCR in the main repository to make that VCR point to the newest version created through the workspace.

Figure 12-12 shows the official dependencies noted in DeltaV with solid lines and practical dependencies with dashed lines.

Figure 12-12. Versioning features and how they depend on each other.