Toward Optimistic Version Control in Architecture

Chapter 1

Introduction

In the not-so-distant past, when architectural drawings were rendered exclusively by hand, the constraints of physical space made it impractical for more than one draftsman to work on the same drawing at the same time. Today, computers have liberated architecture professionals from the physical constraints of the drafting board, yet concurrent work on a single drawing or model remains problematic, if not impossible. This persistent limitation restricts the ability of design teams to collaborate, iterate, and explore alternative solutions where digital assets are involved.

Most design software today employs some form of resource locking, which actively prevents a second user from modifying a digital asset as long as the first one is working in it. Often times, the digital asset is a shared file on a networked storage device. Because a single file may represent significant portions of, if not an entire design project, locking this file has the effect of shutting out any potential real-time digital collaborators. Resource locks can also occur at finer levels of granularity than an entire file: In database management systems, it is common for locks to be applied only to a single table or record at a time, and in the case of Autodesk's Revit software, elements within a workshared building information model may be locked individually (Figure 1.1). However, greater granularity does not solve the underlying problem of resource locking; it merely splinters it into scores of smaller potential conflicts.

Resource locking exists to prevent data loss and corruption due to conflicting edits; if only one user is allowed to modify a file at any given time, no conflicts can occur. Although this is a straightforward and effective strategy for handling conflicts over shared digital assets, it is fundamentally pessimistic because it assumes that parallel edits to a file will invariably result in data corruption. The wholesale embrace of this form of digital pessimism by contemporary design software represents a significant obstacle to parallel work within a design team (Aish 2000).

In the field of software engineering, parallel work on digital files is made possible by the use of version control systems (VCSs) such as Git, Mercurial, and Subversion. The nominal purpose of these systems is to track the changes made to a codebase over time, but they also enable developers to work independently on parallel versions of a project (known as branches) and to later integrate (or merge) their contributions with those of their teammates with little or no extra effort. Modern VCSs are said to be optimistic because they assume that conflicting edits to the codebase are rare and that those that do occur can usually be resolved automatically (Kung and Robinson 1981).

Optimistic version control relies on the ability to find the differences between two versions of a file (a process known as diffing), to apply a list of differences to a file to transform it from one version to another (patching), and to combine lists of differences from divergent versions of a file to arrive at a single, unified result (merging). Well-established and highly optimized algorithms exist for performing these tasks on plain text files such as those used by developers to store source code, which consist solely of sequences of characters grouped into lines. The straightforward and predictable structure of plain text files allows this relatively simple set of algorithms, which form the basis of contemporary VCSs, to provide diffing, patching, and merging functionality for a wide variety of programming languages and data formats.

Not all files, however, are composed of plain text. Images, CAD drawings, and 3D models — the types of files most frequently used by architects — consist of idiosyncratic representations of both textual and non-textual data. The diffing, patching, and merging algorithms used by existing VCSs are unable to operate meaningfully or efficiently on these so-called binary files because they cannot be interpreted as a linear sequence of standard character codes. In fact, existing VCSs will not even attempt to calculate diffs or perform merge operations on binary files, and will instead fall back to older, more pessimistic methods of handling them that do not allow for parallel modes of working (Chacon and Straub 2014; Collins-Sussman, Fitzpatrick, and Pilato 2011). The difficulty in dealing with binary files is that the structure and semantics of each binary format is essentially unique. Just as each image format uses its own method of storing pixels and each type of 3D model employs a different means of representing geometry, the algorithms for diffing, patching, and merging these disparate data formats must be similarly specialized. In order to bring parallel working and other benefits of modern VCSs to the field of architecture, systems for diffing, patching, and merging each of the various file formats used by architects must be designed and implemented.

This thesis describes a set of programs that implement diffing, patching, and merging algorithms for a 3D model format commonly used by architects, namely the openNURBS format native to McNeel’s Rhinoceros 3D modeling software. This format was chosen for its open-source status and its widespread use during the early stages of design when collaboration and rapid exchange of ideas is crucial. Although openNURBS is the focus of these programs, their underlying data model is designed to be abstract enough to support diffing, patching, and merging of other file formats as well.

This thesis also demonstrates how its diffing and merging programs can be integrated into an off-the-shelf VCS, thereby enabling optimistic version control for openNURBS models under its purview. In doing so, this thesis takes the first steps toward bringing the kind of collaborative and concurrent work currently enjoyed by software developers to the practice of architecture.