11.1 Introduction to Versioning

Versioning functionality solves a few common user problems. These problems are so universal that they can be experienced even by a single user working on a single file on a local machine. We approach versioning first from the point of view of solving these simple problems. Only in later sections do we need to address more complex issues introduced by multiple simultaneous authors or multiple related files.

Document and source versioning software has a long history. The industry has accumulated a raft of terminology, unfamiliar perhaps even to those who already use source control software (some of the most advanced versioning software that exists). There are large differences in how versioning problems are solved, so even a reader familiar with one source control system must pay attention to terminology in case it's used differently. This chapter introduces the DeltaV terminology, with a quick reference to other terminology that you might be familiar with.

11.1.1 Simple Problems

Nearly everyone who has ever worked on a document on a computer has saved the document only to realize that they have just deleted something important. Once the file has been saved, typically the change can't be undone. This type of mistake is frustrating and inconvenient, so vendors of software applications attempt to do something about it. How can software allow users to quickly fix a mistake that has been saved in the file? One way is to save a backup copy of the file. The first save creates a file; for example, overview.doc. The second save moves overview.doc to overview.bak and saves the new work as overview.doc.

With this approach, the user can recover at least one older copy of the document. The user had better hope that the missing material wasn't deleted in the next-to-last copy as well! The next obvious step is to keep more past copies around. Application software can automatically store and track a number of past versions of a file (either storing versions locally or on a network file server). Typically, versions are numbered, so the software can create in sequence overview.doc-v1, overview.doc-v2, and so on. Once the application creates the version, it should never be altered.

Having application software store versions as normal files is problematic: Only that application knows that the files are past versions and are not intended to be edited. The application software creates a mess of files, and the user doesn't know if those files can be deleted or edited. It would be a lot cleaner if the file system could handle the versions. A file system that supported versioning could display the main file, hide all the old versions, and only pull them out when they're needed. The application software probably needs to know a little bit about what's going on in order to help the user access older versions, but mostly the file system can take care of the versioning.

The file system can expose information about each version, such as the time it was created and who saved it, in order to make it a little easier to select the right older version. With this information available, you can see that recovering from mistakes isn't the only kind of problem versioning can solve. Version information can help a user find out:

• When did I introduce specific material into (or remove material from) the document?

• What did the document look like on a given date?

• Was this change made at the same time as some other change?

Although these aren't often pressing problems in document repositories, it can be useful to be able to figure out what happened in the past. In source code, however, bugs are sometimes introduced accidentally to code that worked before. It can be very important find out exactly what a source file contained in the past (when the code worked) to be able to quickly and properly fix the bug.

11.1.2 Versioning and Backup Functionality

For users who are familiar with powerful backup software, versioning may seem very similar to backup functionality, and it is. Versioning and backup solve many of the same problems in different ways, and neither feature is quite a substitute for the other. Many systems employ both if storage is rather cheap compared to the cost of loss of information. Some quick points of comparison between the two:

• Storing versions as local files won't help you if your hard disk crashes. The local file system should be backed up even if versioning is used.

• Storing versions on a server (such as a network share) may still involve a single point of failure if the server's hard disk crashes. The versioning server's file system should be backed up, too.

• Backups take snapshots at a fixed point in time. In a daily backup system, only one daily copy will exist, even for a file that has changed greatly in that one day. There may be redundant daily copies of a file that hasn't changed in months. In contrast, versioning takes a snapshot only when the file changes, so the versions more closely reflect the change history.

• Backup systems typically require an administrator to set up, manage, and restore lost files. In contrast, a local versioning system allows users to retrieve older versions without administrator assistance. Versioning systems may even be simple enough to be installed by any user (e.g., if your local file system kept version history from the day you installed the operating system).

11.1.3 Basic Versioning Components

The core components of any versioning system are pretty much the same:

• Versions are the past instances of a resource. These are historical only, not modifiable.

• Versioned files are those files for which the repository maintains a history of versions.

• Unversioned files may still exist in the same repository. The server may not maintain a history of all resources.

• Folders still exist and frequently hold both versioned and unversioned files, even in the same folders. However, ideally versions do not show up in the same folders as the versioned and unversioned files, because users tend to want to "clean them up" (see Figure 11-1).

  Figure 11-1. Common versioning components.

  

11.1.4 DeltaV Data Model

DeltaV is the specification that extends WebDAV to introduce versioning. DeltaV is also the name of the working group where the DeltaV specification was developed.

DeltaV was designed based on a consistent data model extending the WebDAV data model. The data model provides the framework for all the versioning functionality. The model doesn't dictate how data is stored on the server, but it does identify the elements on which operations may be done and how they must be represented. The data model is similar to that of many existing versioning systems.

The DeltaV data model defines a few new resource types and many new live properties. Many of the live properties simply contain URLs to other resources, and these properties serve as links between resources. This gives the implementor a great deal of flexibility to put resources in custom locations on the repository. Rather than store two related resources in the same directory, the implementation can store them anywhere and use the live properties to expose the relationship.

Thus, clients must not make assumptions concerning the location of DeltaV resources. The server may well host special DeltaV resources in the same collections as non-DeltaV resources the same collections that an ordinary Web browser or WebDAV client might browse. Some resources may not actually appear as static resources in static collections, instead being generated dynamically to appear at the URL the server designated.