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 210 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.
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 FeaturesThe 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).
12.7.2 Advanced FeaturesThe 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.
12.7.3 Core Versioning PackageThe 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 PackageThe 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:
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 PackageIn 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:
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 DependenciesThe 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.
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. |