Transactional Editing: Giving ACID to Programmers
Collaboration among programmers today mostly relies on file-based version control systems. These systems typically use optimistic locking to enable parallel work, which means 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 consistency and isolation known from transactional databases can be enforced in the context of collaborative programming. We do so by formalizing 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 (a) perform the edit sequence in isolation from others, and (b) to achieve global consistency before committing. Since our approach is graph-based, it grants us much finer locking granularity than file-based version control.
Tue 22 Oct Times are displayed in time zone: (GMT+03:00) Beirut change
|16:00 - 16:20|
|16:20 - 16:50|
|16:50 - 17:10|
|17:10 - 17:40|