Transactional editing: giving ACID to programmers

Abstract

Collaboration among programmers today mostly relies on file-based version control systems. These systems typically use optimistic locking to enable parallel work, meaning that competing edits (edit conflicts) are detected and have to be resolved at update or commit time. While merging edits can partly be automated, it is an error-prone task that can introduce inconsistencies. Pessimistic locking of the files to be edited does not appear to be a popular alternative, however, and in any case is insufficient to avoid inconsistency, since it does not account for the dependence of (code in) files on others. To address these problems, we show how the notions of atomicity, consistency, and isolation known from transactional databases can be enforced in the context of collaborative programming. We do so by presenting editing as a set of primitive edit operations applied to an abstract syntax graph overlaid by a constraint graph expressing the consistency criteria mandated by the rules of well-formedness of a language, and by deriving for every sequence of primitive edit operations the write- and read-locks sufficient to: perform the edit sequence, either completely or not at all, in isolation from others; and to achieve global consistency before committing.