May, 2002

Welcome new subscribers. Our feature article describes how upside-down versioning (used in TrueCM) resolves versioning problems of the past by getting back to the basics of version control. Your feedback and suggestions on this article are encouraged. Simply reply to this message, or send to support@truebluesoftware.com.

Topic Index:

• CM Concept: Upside-Down Versioning
• New TrueCM Release
• TrueCM Tips & Tricks
• Subscriptions

CM Concept: Upside-Down Versioning

The wide-spread use of version control tools testifies to their benefit in software development. Yet recent advances in version control concepts are shaking up the established tools. This article traces the development of version control concepts and technologies, continues with a description of the upside-down project versioning concept, and ends with its application in modern version control tools.

In the Beginning

When software programs were written first on paper, one could physically hold one's program. Versioning involved keeping old copies of program files. When programming was moved on-line, the physical copy model was replaced by whole file (or whole set of files) copying. This similarity to the physical model of development was so compelling that it was built into some operating systems (VAX/VMS being one example) and is still frequently used today (ever made a .bak file?), largely because it is so easy to understand.

Whole file copying was a somewhat costly solution because on-line storage was pretty expensive at that time. It was also a problem because the relationships between the project copies were not tracked, nor were the relationships between corresponding items in the copies. Only convention (or external data) stored the relationship between two project copies. And if convention was broken (file names or locations were changed) in one copy, the implicit relationship with that item in other copies was lost.

Summary: Storing complete copies of project files was simple and easy to understand, required no special tools, and could represent any state of a project without constraint. But it used lots of expensive disk space and did not preserve the relationships between versions of the project or between versions of files in the project.

Delta Storage

Delta storage addressed most of these problems by efficiently storing multiple revisions of a file in a single delta file, and by providing tools for managing the archive. Tools like SCCS saved much disk space, preserved the relationships between individual file revisions, and provided tools to compare revisions. But as often happens when you solve the problem in front of you, the solution itself presents unanticipated challenges.

Two problems arose. The first was that a file name was not sufficient to identify a file's content: you also needed a revision selector. As long as you could use the newest revision (no parallel development), this was not a problem. But in a theoretical (and increasingly practical) sense, this introduced significant complexity by requiring a revision choice for each file access. And these choices were interrelated because the file revisions selected for a particular project version needed to be consistent. In fact, nearly all possible permutations of file revisions would result in an inconsistent and probably meaningless version of the project as a whole.

The second problem was that the file name was the key to access an archive file. In particular, file names and directories and other attributes could not be different between project versions. These attributes simply were not being versioned.

Summary: Delta storage provided dramatic disk space (cost) savings and recorded the relationships between revisions of a file. But project level version relationships were not understood, file revision selection became necessary, and file and directory names were not versioned.

Version Threading and Attribute Versioning

Two advances were introduced to solve these problems. First, revision labels were introduced to the delta file so that a project-wide identifier could select the individual file revisions that composed a project version. With RCS symbolic names, it became practical to perform parallel branch development using a single set of delta files. Second, the introduction of versioned directories enabled different project versions to have different file and directory names and even different sets of files.

Yet problems remained. Foremost was the complexity and fragility of the revision selection mechanisms. The complexity resulted from the inherent need to select a revision from each file or directory at every access (and while labels helped, the labels had to be set and maintained, which also added significant complexity). The fragility was also fundamental to the solution in that several relevant attributes, as well as the selection rules themselves, were not versioned. This resulted in a situation where the same selection rules applied today and applied tomorrow might yield different results. And project level versioning was still not directly understood.

Summary: Revision identifiers and file attribute versioning provided a mechanism for selecting a consistent set of revisions and for versioning of file attributes beyond a file's content. But project version relationships were still not understood, file revision selection was becoming increasingly complex and fragile, and most critically, the symbolic names and rules for selecting a consistent set of revisions were not themselves versioned by the tools.

Upside-Down (Static Project) Versioning

Modern version control solutions are directly addressing the need to version projects as a whole, and manage the relationships between project versions. Static project versioning does this by turning upside-down the popular dynamic file indexed by project-revision selection model, replacing it with a project-revision containing files static model. Rather than selecting files first, and then selecting revisions of files, static versioning starts with the project revision. The project revision then selects (or contains) all file attributes, including the proper file content. Static versioning is fundamentally different in several areas:

1. Static project versioning is inherently more robust than file based selection. It is simply easier to choose from among a few consistent and meaningful versions of a project, than to select consistent and meaningful project versions from a collection of revisioned files.
2. Static project versioning is more robust. Dynamic (or intentional) selection rules are dependent on the environment in which they are evaluated. A rule can remain unchanged yet evaluate differently simply because of a change in the environment. For example, in RCS, changing the value of a symbolic name will affect the evaluation of a dynamic rule which uses the symbolic name. With static versioning, only a direct change to a project version will affect that project version. Side-effects are eliminated and project version preservation becomes robust and reliable.
3. Static project versioning is inherently higher performing. Two project versions can be compared by comparing their lists of attributes. When using dynamically evaluated project-revision selection rules, each rule must be evaluated for each file and directory, a time-consuming approach.
4. Static project versioning is conceptually closer to how we actually work and think. Productivity improves dramatically because the tool can directly represent what you are modeling. And because the objects are real, you can directly interact with that model. The resulting project-level branching, tagging and merging operations provide conceptual, reliability and performance advantages over file at a time tools.

Static project versioning provides the conceptual simplicity of the whole-copy versioning approach, the elimination of the version selection problem, the relationship tracking and space-saving advantages of the best delta storage tools, and full attribute versioning. By versioning projects, and directly representing the relationships between project revisions, project-level operations become the norm for branching, tagging and merging.

Summary

Static project version control, as implemented in TrueCM, provides a dramatic reduction in versioning complexity by narrowing focus to a meaningful subset of all possible configurations, and by directly providing project-level operations. It also increases reliability by versioning all relevant file attributes.

Each of the described historical advances was significant in its time. Only as each new level of capability was developed, used and stretched, did a better future become visible and the conceptual and technological solutions develop to realize that future. Modern version control solutions are reaching a new, higher plateau. While work remains to build a solid base for further advancement, the future is bright. In an up-coming issue of this newsletter, we will explore some directions in which even higher plateaus may be found.

Reference: Static project versioning was brought to the author's attention through the following paper: An Inverted Approach to Configuration Management, D. B Miller, R. G. Stockton, Charles W. Krueger, Proceedings of the 2nd International Workshop on Software Configuration Management, October 24, 1989, Princeton, NJ, USA. ACM Press, 1989, 1-4. Unfortunately, this article does not appear to be available on-line.

TrueCM Release 1.30

Several significant new features continue to enhance TrueCM's capability. The highlights:

• Added Properties support to SCC integration
• Improved interaction with VS.NET
• Usability improvements as a result of usability testing
• Addition of a recent projects list to the GUI
• Ability to recover deleted files in a snapshot
• Ability to unlink rather than delete files
• Significant TK Diff tool improvements
• Ability to rollback a snapshot
• Several new file viewing filters in both the GUI and the wls command.
• Detailed list of changes.

Register for an evaluation version here. Existing customers may go directly to the normal download location to obtain the latest release.

TrueCM Tips & Tricks

We'd like to make this a regular feature, and your suggestions will help make it so. Send your TrueCM Tips and Tricks to support@truebluesoftware.com for inclusion in a future newsletter.

• To easily check in all locked files in your workspace, select the root folder in the Snapshot Folders pane, choose the File->Check In... menu, and check the Recursively check box.
• To check in all modified files in your workspace, select the View Files Needing Check In Recursively filters in the Workspace View, select one of the files in the Workspace View list (to set focus to that list), press Ctrl-A to select all the files, and press the blue left-pointing arrow.
• To quickly see what has changed for a file in your snapshot compared to the parent snapshot, select the file and then select the File->Show Differences... menu item. In the Rev1 field, select parent snapshot. In the Rev2 field, select My Snapshot or Workspace and then OK.
• Did you know that (almost) anywhere TrueCM accepts a revision, it accepts either the revision number as shown in the history, or a snapshot path to select the revision referenced by that snapshot. Another tip: snapshot paths interpreted as revisions can be given either as full paths, or as paths relative to the current snapshot. The current snapshot is ".", the parent snapshot is referenced by "..", a sibling snapshot as "../sibling", and child snapshot as "child", etc.

Newsletter Subscriptions

To be added or removed from the True Blue Software News mailing list, send your request to support@truebluesoftware.com.

View previous newsletter. View next newsletter.