A version control system (VCS) is a set of software tools that track and manage the changes made to a collection of files over time. The collection of files and their respective histories managed by a version control system is commonly known as a repository. Although traditionally used for organizing the source code of computer programs, version control systems are now being used by writers, lawyers, journalists, musicians, graphic designers, and others.
The first software that can be recognized as a version control system was developed at Bell Labs beginning in 1972. The Source Code Control System (SCCS) was notable for its space-efficient storage system, which accumulated all versions (both past and current) of a document into a single file (Rochkind 1975). One downside to this approach was that the system would become progressively slower with every new version stored. To work around this and other deficiencies in SCCS, the Revision Control System (RCS) was developed around the concept of reverse deltas. RCS stores the most recent version of a file along with a separate reverse delta to describe each of its version transitions; it reconstructs previous states of the file by applying those reverse deltas sequentially to “rewind” to the target version. RCS is significant for introducing the concept of symbolic labels, better known today as tags, that could be used to reference specific versions of a file independently of its internal version number. It also included the ability to create and merge branches — parallel histories by which a developer could experiment in a file without interfering with the work of their teammates (Figure 2.1). However, the significance of this feature was unappreciated at the time and its use was generally avoided (Tichy 1982; Tichy 1985; Ruparelia 2010).
Figure 2.1. Branching and merging. Two students decide to create their own variations on Le Corbusier's iconic Modulor Man (A). The first sends him on vacation in Mexico (B) while the second assigns him to duty aboard the USS Enterprise (C). Confident of her changes, the second student merges them into the main branch (D). The first student subsequently merges those changes into his own branch (E). Woefully deficient in his knowledge of science fiction franchises, he then decides to equip the Modulor Man with a lightsaber (F). The first student then merges his changes into the main branch as well (G).
Both SCCS and RCS are limited to working with a single file and on a single computer at a time. The first of the so-called second-generation VCSs, known as Concurrent Versions System (CVS), was originally implemented as a set of shell scripts that extended RCS to allow it to work with multiple files and over a network. CVS places the version control repository on a central server from which clients can check out an existing version of a file, work on a copy of that file independently of other users, and then check in their changes once complete. It also popularized branching and merging operations to enable the kind of parallel, collaborative workflows that are the hallmark of optimistic version control (Grune 1986; Berliner 1990; Ruparelia 2010). The successor to CVS, named Subversion, was initially released in 2000 and focused on fixing flaws in CVS rather than new innovations in version control design (Collins-Sussman, Fitzpatrick, and Pilato 2011). Its emphasis on power and usability has made it the preferred choice for centralized version control.
In contrast to their predecessors, the third generation of VCSs are inherently decentralized. These distributed version control systems (DVCS), which include Git, Mercurial, and Bazaar, maintain a full copy of the repository on each machine where it is being used to eliminate the single point of failure presented by a centralized server. Such systems are also more performant than their centralized counterparts since most operations can be performed locally without the need for network access to communicate with a central server (Chacon and Straub 2014). DVCSs, and Git in particular, manage the majority of version control repositories in use today.
The decentralized nature of DVCSs does not preclude the use of a central server; in fact, most projects using a DVCS rely on a central repository to facilitate coordination among team members and to act as a single source of truth for build processes and public releases. This central repository often resides on a repository hosting service such as GitHub, GitLab, or Bitbucket, which provide a web-based graphical user interface (GUI) to the VCS and integration with tools such as bug trackers, build systems, and wikis. These services have contributed to the popularity of DVCSs, as well as to the adoption of VCSs in general outside the software development community.
2.2Diffing, Patching, and Merging
Diffing is the process of finding the differences between two versions of a file. In the same way that coordinate geometry allows us to subtract two points to produce a vector that translates between them, diffing can be thought of as the subtraction of two files to produce a directed delta that contains the information necessary to transform one of those files into the other. Patching is the process of applying that delta to one version of a file to transform it into another version. If diffing is comparable to subtracting two points in coordinate geometry, then patching is analogous to adding a vector and a point to arrive at a new point (Figure 2.2).
Figure 2.2. Diffing and patching. Some misguided soul has "improved" upon Le Corbusier's Maison Dom-ino by removing the staircase and adding a ladder, a weather vane, and a human figure. Diffing the two versions of this iconic image is analogous to subtracting the original version from the new one (top row). Patching is analogous to adding that difference to the original version to recreate the new one (bottom row).
Algorithms for diffing and patching are among the most fundamental components of any VCS. The term diff itself originated from a program developed by James Hunt, Thomas Szymanski, and Douglas McIlroy at Bell Labs in the early 1970s. It relies upon a novel solution to the longest common subsequence (LCS) problem to detect which groups of lines are shared between two text files, and thus indirectly indicates which lines have changed (Hunt and McIlroy 1976). A more efficient algorithm for solving the LCS problem discovered in the 1980s forms the basis of all diffing operations carried out by modern version control systems (Myers 1986).
Figure 2.3. Three-way merging. A three-way merge requires that the two files being merged (A and B) originate from a common ancestor (O). The operation compares each of the two files with the common ancestor (ΔA and ΔB) to arrive at a more accurate result (M) than was possible with older and less reliable two-way merging algorithms.
Merging is the process of combining the sets of changes made in two divergent versions of a file to arrive at a unified result (Figure 2.3). Users of VCSs employ merging to reconcile the changes made by others with their own working copy of a project, thereby bringing their copy up to date with the rest of the team. Because of its role in eliminating the need for resource locks, it is not an exaggeration to state that merging is what makes optimistic version control possible (Mens 2002).
The merging algorithms used by nearly all contemporary VCSs are designed to work with plain text, a data format consisting purely of sequentially-arranged, human-readable characters (The Unicode Consortium 2021). Regardless of their content, all plain text files adhere to a common structure consisting of sequences of characters grouped into lines. The power and popularity of these algorithms arise from this consistency; because they are able to ignore the syntactic and semantic content of the files they are given, these algorithms can operate equally well on C source code as with the LaTeX files used to typeset this thesis. Neither obscure nor yet-to-be-invented file formats pose any challenges so long as their contents are textually encoded.
Not all files, however, are composed of plain text. Binary files such as images, videos, and 3D models consist of domain-specific and application-dependent encodings of both textual and non-textual data. Because these files do not adhere to a consistent structure of characters and lines, the merging algorithms embedded in most contemporary VCSs are unable to operate effectively on them (MacKenzie, Eggert, and Stallman 2021a). The idiosyncratic structure of binary files makes it likely that any attempt to merge them using textual merging algorithms would result in syntactically invalid and possibly semantically nonsensical output — images that won't load, videos that won't play, and 3D models that crash their modeling programs.
Contemporary VCSs handle any modification to binary files, no matter how small, by storing an entirely new version of the file in the repository. This strategy precludes the benefits of change tracking and asynchronous, parallel collaboration for such resources, making it the single largest technical hurdle to the availability of optimistic VCSs for the architecture profession. A number of structurally- and semantically-aware algorithms that could enable merging of binary data have been proposed (Rönnau, Scheffczyk, and Borghoff 2005; Chen, Wei, and Chang 2011), but none have gained widespread acceptance in version control applications.
2.3Benefits of Optimistic Version Control in Architecture
The vast majority of design professionals today handle the storage of alternative and past versions of a project by manually copying and renaming files. This highly idiosyncratic process is prone to errors and data loss and imposes an unnecessary cognitive burden on the computer user (Ashtari 2018; Cristie and Joyce 2021). VCSs offer a standardized, automated, and reliable method of managing alternative and past versions of a design that scales to accommodate design teams of varying sizes. They enhance the collaborative potential of design teams by enabling their members to work in parallel. Beyond these more prosaic benefits, adoption of version control techniques may actually help to augment an architect's creative potential as well.
Modern VCSs enable a non-linear view of history that encompasses not only the depth of time but also the breadth of alternatives inherent in any design project. The processes of differentiating and synthesizing alternatives are known respectively as branching and merging within the parlance of version control systems, and offer compelling parallels to the patterns of divergence and convergence seen in the design processes (Cross 2006). Adopting version control practices could heighten architects’ awareness of their place in the design process, and thereby increase their capacity for reflective practice
(Schön 1984; Cristie, Ibrahim, and Joyce 2021).
Placing a project under version control creates a digitized memory of every step (and misstep) of that project’s development. This memory can augment the designer’s own thought processes and facilitate idea navigation during the design process, and can afterward act as an archive not only of the final outcome of the design process but also of the designer’s ideas and intent as well (Cristie, Ibrahim, and Joyce 2021). Such an archive could be consulted by the designer or his associates in the months and years after a project has concluded, or by architectural historians decades later. It can also provide novice designers valuable insight into the more decisive decision-making process of their expert colleagues (Cross 2004).
Within the scope of architectural education, version control could also facilitate a digital reincarnation of the open design atelier, which has suffered in recent years due to the increasing prevalence of digital-only workflows as well as physical distancing driven by the recent pandemic (Meagher et al. 2015).
Recognizing the need for tooling specifically designed to handle multiple versions of a design, some architecture firms have begun to take advantage of cloud-based document management systems such as Autodesk’s BIM 360. While these products represent a huge step forward in terms of collaboration and data integrity, they still suffer from the constraints of resource locking. Furthermore, they are limited to a linear model of the project’s history, making them poorly suited to handling multiple design alternatives in the early stages of a design project. Only optimistic version control can enable the kind of unrestricted parallel work currently enjoyed by software developers in the field of architecture (Schneider 2011; Firmenich et al. 2005).
2.4Research into Version Control for Architecture and Related Disciplines
The need for version control tools in architectural practice has been recognized since at least 2000, when Robert Aish reported on the implementation of “long transaction” and “change merge” features (which would be recognized today as branching and merging, respectively) in Bentley’s since-discontinued ProjectBank product (Aish 2000). However, the most promising work in the development of diffing and merging algorithms for visual designers has instead dealt with file formats used by digital animators and illustrators for 3D modeling. Doboš and Steed (2012) proposed the first system for diffing and merging these 3D scene graphs. Their node-based method relies on matching the universally unique identifiers (UUIDs) assigned to model components to determine which ones have been added to and removed from the model. However, their approach to change detection is insufficiently granular to support collaboration.
3D scene graphs typically use meshes, networks of planar, polygonal surfaces, to approximate complex forms rather than attempting to model their curvature directly. MeshGit is an algorithm for determining the edit distance between two meshes as a means of implementing diffing and merging for that style of geometry (Denning and Pellacini 2013). Its original implementation suffered from a number of performance issues and was subsequently improved in MeshHisto to be precise and scalable enough for real-time collaborative editing (Salvati et al. 2015).
SceneGit likewise improves on MeshGit through the addition of performance-enhancing heuristics. It defines a comprehensive set of data structures and algorithms for diffing and merging not only the geometry of a 3D scene graph, but also its materials, lighting, and camera configuration. Because it focuses on interchange formats (namely OBJ and gITF) in which UUIDs are frequently missing or unreliable, SceneGit also implements a novel method of deriving unique but stable object identifiers across file versions. SceneGit represents the state of the art in diffing and merging 3D models at this time (Carra and Pellacini 2019).
Doboš et al. (2018) proposed an alternative method of detecting differences between different versions of a 3D scene by comparing the pixels of coordinated rendered views. The downside of this approach is that it is unable to detect differences that are not visible in the rendered view, such as small changes in the geometry of a large-scale model or modifications to non-visible attributes, making it unsuitable for use in a VCS.
Daum and Borrmann (2016) present a system for diffing and merging architectural models that employ the Industry Foundation Classes (IFC) schema, an open standard for storing building information model (BIM) data. GeomDiff includes a similar set of algorithms for geospatial data, notably describing changes in geometry in terms of the movement of points rather than the substitution of new values for old ones (Sveen 2020).
GHShot is a web-based VCS for Grasshopper scripts, a visual programming language used by architects to develop parametric models in Rhinoceros. In this system, a custom Grasshopper component communicates with a server to record the editing history of a Grasshopper script. Unfortunately, this approach lacks the necessary level of separation between the VCS and the content under version control: In order for a Grasshopper script to be managed by GHShot, it must itself contain the GHShot software in the form of the custom component (Cristie and Joyce 2017; Cristie, Ibrahim, and Joyce 2021).
Sakai and Tsunoda (2015) created LMNArchitecture, a web application that presents the evolution of simple architectural models as an interactive tree diagram. The models are stored in a text-based format so that off-the-shelf diffing and merging programs can be used.
Most existing VCSs take a state-based approach to merging that considers only the differences between two versions of a file and not how those differences arose. In contrast, Koch and Firmenich (2011) propose an operation-based approach to collaboration within an architectural model whereby the actions taken by one user are transmitted to another user’s computer and applied to that user’s copy of the same model, in much the same way that online collaborative editors such as Google Docs synchronize changes among users. Operation-based merging tends to benefit from better conflict detection and resolution than state-based approaches, but also requires deep integration with the software used to edit the files in question.
